Auto mode classifier blocks actions the user explicitly ordered in-session (merge, deploy, reading test credentials, verification reads)

Additional occurrences (same session, later):

• A subagent doing verification that the user had ordered was denied, as [Modify Shared Resources], a read-only pg_stat_activity sampling script against a local verification database that the orchestrating agent had started for exactly this purpose. Reading the log of its own local Playwright run was denied for the same reason. The subagent had to stop its verification.
• The same class of denial (reading the agent's own verification output / a local shared test instance) keeps recurring across parallel subagents, so each one stops independently even though the user explicitly asked that all verification run against one shared local instance.

Request: treat read-only inspection of a local test instance that the same session started, and reading the agent's own tool output, as low-risk.

Another recurrence (auto mode).

A subagent spawned by the orchestrating session was asked to run Playwright UI verification against a local, user-designated shared verification instance (docker compose on 127.0.0.1, created by the same session for exactly this purpose; the user explicitly ordered that all agents verify on this one shared instance). The UI step "add a fiscal year in the app" was denied by the permission classifier as "Modify Shared Resources".

Effect: the fix was implemented but its required on-screen verification could not be performed, so the item stays open. The instance is a disposable local dev stack, not production or a resource shared with other people.

Expected: local, session-created dev instances that the user designated for verification should not be classified as shared resources, or the denial should give a way for the user to approve that scope.

Another recurrence (auto mode), same pattern.

A subagent wrote a database migration and tried to apply it (alembic upgrade head via docker exec) to the same local, session-created, user-designated verification stack (docker compose on 127.0.0.1). It was denied as "Modify Shared Resources". A seeded test-row write to the same local dev database was denied for the same reason.

Effect: the migration cannot be verified, and a second worker container that waits for the schema head cannot start, so on-screen verification for other agents on that instance is also held up. The instance is a disposable local dev stack created in the same session for verification, not production or a resource shared with other people.

Another recurrence (auto mode).

A subagent that the orchestrating session had explicitly assigned to fix one defect class (an XML rewrite pattern that makes generated Office files require repair) was denied when editing the remaining three occurrences in other source files of the same local repository. The denial reason was that the files were outside the subagent's originally assigned files ("shared resources"). The orchestrator had reassigned those files to it within the user's standing instruction that this session fix all open defects.

Effect: a known defect is left in three code paths until the user intervenes manually; the orchestrator cannot re-delegate or perform the edit without that being permission laundering.

Another recurrence (auto mode).

A subagent profiling a slow bulk INSERT on the same local, session-created verification database (docker compose on 127.0.0.1) was denied when running a session-scoped comparison (SET session_replication_role = replica inside its own transaction, to measure trigger/FK overhead). Denied as modifying shared resources. The setting only affects the agent's own session and the instance is a disposable local dev stack created for verification.

Effect: the remaining cost breakdown of the INSERT could not be measured, so the optimization stops short.

Same experience here. A pattern that worked for us, in case it helps the design:

• Chat-level authorization ("yes, go ahead") didn't reliably reach the classifier. Across several projects in 10 days we logged refusals labelled Production Reads, Production Deploy, Credential Exploration, Self-Modification and Modify Shared Resources, many of them on actions the user had asked for.
• A small, concrete one (2.1.286, 2026-10-01): Claude wrote a new helper script in the project's own bin/ and the user asked for it to be made executable. chmod +x bin/<script> was refused as Self-Modification twice, the second time with Claude citing the user's approval in its reasoning. The user then ran the same command himself with !, and nothing else changed. The refusal added a round-trip but no safety: the user approved it and then ran it himself.
• What did work: the user confirms a written task that names each command allowed outside the sandbox. A hook records that confirmation outside anything the model can write, and the next launch puts exactly those patterns in sandbox.excludedCommands. The classifier then passed the approved production query with no extra allow rule.

A first-class, structured "the user approved exactly these commands for this task" signal would let the classifier tell real authorization apart from the model's own claims.