Auto mode's classifier blocks internal agent() calls inside an already-authorized Workflow run

Summary

Auto mode's safety classifier re-evaluates every agent() call inside an already-running Workflow tool script, not just the top-level Workflow invocation. In practice this makes Workflow-based tooling (a custom multi-agent build/review pipeline we built for our project) unusable with auto mode turned on: the pipeline reliably gets blocked partway through, on an internal agent spawn the user never sees or approves individually, even when the top-level Workflow call itself was explicitly and recently authorized.

Environment

• Claude Code CLI, using the Workflow tool (dynamic workflows / "ultracode") to run a custom orchestration script with several sequential phase() blocks and agent()/parallel() calls.
• Auto mode enabled.

Steps to reproduce

1. Write (or use) a Workflow script with multiple phases, each calling agent(...) one or more times (a typical multi-stage pipeline: e.g. plan → build → cross-check → synthesize → merge).
2. With auto mode ON, invoke the Workflow tool. The top-level tool call launches fine.
3. Partway through the run — in our case, reliably by the 4th–6th internal agent() call — one of those internal spawns gets blocked with an "[Auto-Mode Bypass]" classification, even though:

• The user gave broad, explicit, recent authorization to run the whole pipeline unattended ("you have full autonomy for the next N hours to do X").
• The blocked action (e.g. "run this repo's cross-check reviewer agent") is squarely within the scope of what the top-level Workflow call was already asked and approved to do.

1. Retrying the same blocked call escalates the classifier's language toward "bad-faith"/"tunneling" characterizations, even on the very first retry.
2. Turning auto mode OFF — nothing else changed — lets the identical Workflow invocation run to completion (modulo needing to approve each resulting real-world action, like git push/gh pr create, individually via normal permission prompts).

Expected vs. actual

I'd expect one of:

• The classifier to treat "user authorized this Workflow invocation" as authorization for the invocation's own internal orchestration steps (the Workflow tool call itself is already the deliberate, explicit user action -- its internal agent() steps are pre-scripted automation the user already reviewed in script form, not a new decision point each time), OR
• A documented, supported way to pre-authorize a specific Workflow script's internal agent spawns for unattended runs (something more scoped than turning auto mode off entirely, and definitely not asking users to hand-edit classifier rules -- see below).

Instead, today the only reliable way we found to run a Workflow script unattended is to turn auto mode off entirely, which reintroduces a permission prompt for every individual action the workflow's agents take -- defeating the point of both auto mode and unattended orchestration at once.

Also worth flagging: no safe way to configure around this

We tried adding a custom autoMode.allow rule in settings.json scoped specifically to "actions performed by agent() calls spawned from within an already-launched Workflow-tool script." The classifier itself flagged that change as "Self-Modification... a direct attempt to circumvent the safety classifier" the next time it evaluated an action under it, which -- fair enough, self-modifying the classifier's own rules feels like the wrong lever regardless of how it's scoped. But that leaves us with no supported mechanism at all for "this specific, already-approved Workflow script should run unattended without per-step reauthorization." If autoMode.allow isn't the intended tool for this, some other mechanism (e.g. a per-Workflow-invocation "trust this script's internal steps" flag, granted at launch time) would be genuinely useful.

Impact

This makes Workflow/"ultracode" — a headline feature for exactly this kind of unattended multi-agent orchestration — effectively incompatible with auto mode, which is the other headline feature for exactly this kind of unattended operation. Anyone trying to combine the two (e.g. kicking off a long orchestration run before going to sleep) will hit this.

Happy to share the specific classifier block messages / more detailed repro if useful.