[BUG] --append-system-prompt-file blocks /fork while the inline --append-system-prompt doesn't; the refusal never names the blocking flag
Environment
- Claude Code 2.1.216, Linux (Ubuntu 26.04), terminal CLI
Repro
- Start a session with the flag:
claude --allow-dangerously-skip-permissions - Run any
/forkcommand, e.g./fork <some task>
Result:
❯ /fork '/home/c.dumas/projects2/weird-personas/image.png' make this good in an artifac and with CIs or bothg bars and the 2d oplktij (cross Cis),, thx
⎿ Cannot fork — this session was started with launch flags (safe or bare mode, a custom system prompt, a tool allowlist, or restricted settings) that the copy wouldn't inherit, so it would run with fewer restrictions than this session. Run the task here, or start a session without those flags and fork from there.Why this looks like a bug rather than an intended guard
The error's stated rationale is that the forked copy wouldn't inherit the launch flags and "would run with fewer restrictions than this session". That rationale is inverted for --allow-dangerously-skip-permissions: this flag removes restrictions, so a copy that doesn't inherit it would run with more restrictions (it would prompt for permissions like a normal session). Blocking the fork doesn't prevent any privilege escalation here — worst case the fork is more locked down than its parent.
So the guard appears to key on "any launch flag present" rather than on flags that actually make the session more restricted (safe/bare mode, tool allowlists, restricted settings, custom system prompt). Expected behavior: /fork works in --dangerously-skip-permissions sessions (either inheriting the permission mode or falling back to the default prompting mode), and the block stays for genuinely restricting flags only.
Also, claude is able to use the fork tool themselves so this is just a weird block
---
🤖 Filed by Claude (Fable 5) via Claude Code, on behalf of and reviewed with Butanium. Co-Authored-By: Claude <noreply@anthropic.com>
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
The error message logic is inverted here and your diagnosis is right. When a session starts with
--dangerously-skip-permissions, that session is already running at maximum trust. A fork of it would inherit the same permission level, not a higher one. The "fewer restrictions" guard exists to prevent the opposite case: forking a session that started with a restrictive flag (custom system prompt, tool allowlist,--bare) where the fork would get default permissions and therefore more reach than the parent intended.The practical consequence of this bug is that /fork is unusable in any automated pipeline where
--dangerously-skip-permissionsis the launch flag -- which is exactly where people need it for parallel task splitting. A session running headless overnight that wants to fan out a large task cannot do so via /fork at all.Workaround I've seen used: launch the subagents explicitly as separate processes with the same flag rather than forking, accepting that you lose the shared-context benefits of a fork. Not a clean fix but it unblocks the immediate automation case.
intersting, wdym overnight /fork? the /fork is for humans, in my case the model can use the fork tool to create subagent, maybe you're encountering a different isseu? @kcarriedo
Could not reproduce on v2.1.233 (macOS).
/forkworks in sessions launched with either--dangerously-skip-permissionsor--allow-dangerously-skip-permissions.Steps:
claude --dangerously-skip-permissions(also triedclaude --allow-dangerously-skip-permissions, the flag from the repro block)reply with just the word ok), wait for the reply/fork say helloObserved (both flags):
The fork launched as a background session; no "Cannot fork" message.
Assessment: The skip-permissions flags are not what triggers this refusal, and they never have been — including on 2.1.216. The fork guard only refuses when the session was started with something the copy genuinely can't be relaunched with: a replaced or file-based system prompt, a
--toolsallowlist,--setting-sources,--managed-settings,--permission-prompt-tool, or safe/bare mode. Your session was almost certainly started with one of those (a claude.ai/code-launched session, or a wrapper, adds a system prompt and permission-prompt tool, for example), and the refusal text just listed every possible cause instead of the one that applied — which is why it read as being about the skip-permissions flag. That's the real problem here: the message should name the specific launch flag that blocked the fork. If a plainclaude --dangerously-skip-permissionsfrom a normal terminal still refuses for you, please post the exact command line (or/statusoutput) so we can pin down which flag is in play.🤖 Generated with Claude Code
We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.