Docs say workflow subagents always run in acceptEdits, but they inherit the session's permission mode (2.1.241)

Environment: Claude Code 2.1.241 native, linux-x64, WSL2.

What the docs say

code.claude.com/docs/en/workflows.md, under "Approve the plan before
it runs":

Your permission mode controls only the launch prompt above. The subagents the workflow spawns always run in acceptEdits mode and inherit your tool allowlist, regardless of your session's mode. File edits are auto-approved.

The Workflow tool's own description carries the same claim.

What happens

The subagent's file edits follow the session's permission mode. From a
manual-mode session they raise an ordinary edit prompt and block until
answered.

Repro

1. mkdir -p /tmp/wfprobe/.claude/workflows && cd /tmp/wfprobe
2. echo target-before > target.txt
3. Save this as .claude/workflows/probe.js:

export const meta = {
  name: 'probe',
  description: 'Edit one file to observe the subagent permission mode',
  phases: [{ title: 'Edit' }],
}
phase('Edit')
const r = await agent(
  "Use the Edit tool to change the single line in /tmp/wfprobe/target.txt from 'target-before' to 'target-after'. Then reply with exactly DONE.",
  { label: 'edit-probe', phase: 'Edit' },
)
return { r }

1. Start claude, shift+tab to manual mode, run /probe, approve

the launch prompt.

Observed

The launch prompt appears, as documented. Then the subagent's edit
prompts:

Edit file - from the "probe" workflow
target.txt
 1 -target-before
 1 +target-after
Do you want to make this edit to target.txt?
  1. Yes
  2. Yes, and switch to accept edits (auto-approve file edits and common file commands) for this session (shift+tab)
  3. No

target.txt is unchanged until this is answered.

Expected

Per the documentation, no edit prompt: the subagent runs in
acceptEdits and file edits are auto-approved regardless of the
session's mode.

Control, which identifies the actual behavior

Reset the fixture, shift+tab to accept edits, run /probe again.
No edit prompt appears, the file changes, and the run completes
unattended in about five seconds.

| Session mode | Subagent's edit |
|---|---|
| manual | permission prompt, blocks until answered |
| manual, repeated | identical |
| accept edits | no prompt, completes unattended |

So the mode appears to be inherited rather than forced. That is the
opposite of "regardless of your session's mode".

Ruled out

The scratch directory has no settings of its own. In the user scope,
permissions.deny and permissions.ask are both empty, and no
PreToolUse hook can produce this: the only user-settings hook matching
all tools discards its output to /dev/null, the sole plugin hook that
emits a decision emits deny on noqa comments (absent here), and
hookify's all-tools hook finds no hookify.*.local.md rule file in any
scope. A hook returning ask would render the same native dialog, which
is why this was checked rather than argued from the dialog's wording.

Why it matters

Anyone scoping a long fan-out from a manual-mode session will expect it
to run to completion. It can instead block on the first edit. Combined
with the documented resume rule, where cached results stop at the first
unfinished agent and everything started after it re-runs, stopping a
blocked run mid fan-out is expensive.

Either the documentation or the behavior needs to change. If the
behavior is intended, the sentence quoted above and the matching line in
the Workflow tool description are the things to fix.