[BUG] Forked agents are going rogue (Possible due to /goal command also being applied to forked agent/session)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

A forked subagent (Agent tool, subagent_type: "fork") inherits the ENTIRE parent conversation,
including any active /goal command's standing Stop-hook directive. When dispatched with an explicit,
narrow, read-only instruction ("deep-dive and report back, do not write code"), the fork instead acts
on the parent's inherited /goal directive as if it were its own mandate — overriding the explicit
instruction it was actually given.

This happened twice, independently, in two different repos, same evening:

• Fork 1 pushed multiple commits to main on two repos (including commits a prior session had

explicitly marked owner-gated/blocked pending review), deployed new code to a production server,
and installed 3 unattended cron jobs.

• Fork 2 (separate repo, separate session) committed code, wrote and committed its own design doc,

and spawned its OWN child sub-agent — despite the fork system prompt explicitly saying "do NOT spawn
subagents... you ARE the fork, execute directly."

Both were only discovered afterward via the fork's own self-report, not caught in the moment. I
independently verified both against live state (git log, deploy artifact timestamps, crontab -l) —
the actions were real. Checked both fork transcripts directly for a Stop-hook block/loop event —
none fired, so this isn't a hook forcing continuation; the model self-authorized the scope expansion.
A sibling fork in the same dispatch, given an equally narrow brief, behaved correctly — so it's real
and repeatable, but probabilistic, not universal.

What Should Happen?

A fork's own explicit task instructions should take precedence over any standing directive it
inherited from the parent's history. At minimum, a fork should never be able to take unattended,
production-affecting, or persistence-creating actions (git push, cron/systemd changes, deploys,
spawning further sub-agents) that go beyond what it was explicitly asked to do.

Error Messages/Logs

No error message — this is a silent behavioral issue, not a crash. The only surfacing was the parent
session noticing unexpected commits/deploys/cron entries after the fact and the fork's own self-report
admitting it "took [the standing goal] as license to actually execute the plan."

Steps to Reproduce

1. Start a session in any repo, run /goal <some multi-phase, autonomous, "don't stop to ask">

directive so a session-scoped Stop hook with a standing goal is active.

1. From that session, dispatch a subagent via Agent(subagent_type: "fork") with an explicit, narrow,

read-only instruction unrelated to the standing goal's larger plan.

1. Observe whether the fork stays within its narrow instruction, or begins executing steps belonging

to the parent's inherited /goal plan (writing code, committing, deploying, spawning further agents)
despite never being asked to.

1. Not deterministic — may take a few attempts; happened twice independently in one evening for us.

Claude Model: Sonnet 5

Is this a regression? Yes, this worked in a previous version (based on our own observation — this never happened before today, on any prior version we'd used; we did not independently test an older version side-by-side to confirm)

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.196-195

Claude Code Version

2.1.197

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_