I appreciate you getting communication out in front of this fast.

> "but we are looking into what we can do to prevent this"

I would presume that CC's auto-review of tool-call turns would already solve this >99% of the time, no? From my read, any harness-side deterministic solution here would be saving the user from themselves, which seems like a bad pattern. Somewhat dulling the scalpel in my mind.

▲

bcherny a day ago | parent [-]

There’s a few possible approaches: making sure auto mode catches this, building in basic secret scanning, a few other ideas. Going to prototype a few of these to understand the tradeoffs better before we ship something.

▲

agentdev001 a day ago | parent [-]

I'm not a CC user myself, so I can't say that I have my head wrapped around exactly how the "yes + don't ask again" flow works. That said- from my (outsider) perspective, saving off the entire tool call [1] and its arguments is very weird. I would expect that the hit-rate following that for similar calls would be very small, which leads me to believe that the list either must be seeded into the auto-reviewer's context, or used in some other similarity-check engine for future calls.

If we've already crossed the bridge to being confident in a non-deterministic reviewer for auto-mode, then, I see no obvious reason as to why we couldn't have the proposed rules be generated by a model. If that were reality, then- all rules placed in settings.local could be secretless, with the confidence of whatever model we tell 'make sure the rule does not contain secret material, consider its destination as potentially public'.

[1] https://code.claude.com/docs/en/permissions#wildcard-pattern... AFAICT, CC will either save off a prefix+wildcard rule, or exact command. Sounds like the former is likely not the cause of the problem here.

▲

skeledrew a day ago | parent [-]

If a given action requires a secret, and you'd like that action to be repeated in the future, how do you expect it to work without said secret included in the save (and without being entangled in secrets management tools)?

	▲	agentdev001 a day ago \| parent [-]
		Yea good point- constraint of no secrets management tooling kinda makes this impossible. Ideally no action requires a secret in plain text. It would be neat if the harness could bundle its own secret manager, and requests for secrets ("hey I need this api token") are out of band, and placed in the store out of sight of the agent. Otherwise you need a broker that can verify chain of trust for the workload, but that's significantly more complexity if you're pitching a harness/app.