[BUG] Auto-mode classifier blocks recording a user's own explicit approval ("Instruction Poisoning"), stalling an approved overnight multi-agent run

Idk if im at the right issue but even after running a session in auto mode its asking for confirmations b2b today

Until the classifier can tell your approval apart from injected text, there's a documented way to take this decision away from it instead of switching to Bypass.

Per the permission-modes docs, an action that matches an allow, ask, or deny rule resolves before the classifier, and subagent actions go through the same order with the same rules. So:

1. Add a narrow allow rule just for the status files, e.g., Edit(/docs/specs/**) (adjust to your path). Narrow rules stay in effect in auto mode.
2. Have the spec agent change the status line with the Edit tool, not Perl. A Perl edit through Bash doesn't match an Edit rule, so it still goes to the classifier.
3. Optionally add a plain-words autoMode.allow entry, e.g. "Agents may set Phase status in docs/specs/** to Approved". Note the classifier only reads autoMode from ~/.claude/settings.json or managed settings, not from .claude/settings.json in the repo.

One exception: writes to protected paths still go to the classifier even with an allow rule, so check your spec folder isn't one.

I'd still keep this open. An approval that only exists in chat text can't be verified by anything, so your last point (declaring delegated authority in config) feels like the real fix.

The classifier-vs-user-approval gap you are hitting is a structural problem: the classifier treats the content of a write (a status marker in a markdown file) as suspicious, with no way to distinguish "this string was injected by an untrusted tool" from "this string was placed here by my own spec-authoring subagent running a workflow I designed and explicitly pre-approved."

Two things that have helped in our multi-agent setup for this specific pattern:

First, the allow-rule approach the previous commenter mentions works, but you can make it narrower and therefore safer: scope the allow rule to the exact file path and the exact edit pattern (a regex anchored to the specific status line), rather than allowing the whole file or the whole command class. That way you are not widening the bypass surface for anything else the subagent might try to write.

Second, the deeper fix we use is to move the "approval gate" out of the file content and into the filesystem structure. Instead of having the subagent write "Phase status: Approved" inside a file, it creates a separate .approved sentinel file in a known directory. The conductor checks for the sentinel file's existence rather than parsing file content. The classifier does not flag file creation the same way it flags in-place edits to markdown status fields, so the gate works without triggering the instruction-poisoning path. It is a workaround for a classifier gap, not a real fix, but it has been reliable for us.

The underlying request -- that the classifier respect explicit user-originated approvals given in the main session -- is the right fix. What you are describing is a legitimate pre-approved workflow being treated as adversarial because the approval text lives in the conversation rather than in a structured permission primitive.