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.

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)?

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.