Claude Code’s Agent tool spawns subprocesses that run autonomously. The parent sends them off to do research, write code, or run tests, then waits for results. When it works, it is the most powerful feature in the toolkit. When it does not work, it fails in ways that are hard to diagnose because the failures are silent.

This is a catalog of what actually goes wrong, drawn from community reports in the past week. If you run agentic workflows with Claude Code, these are the failure modes to watch for.

Permissions do not propagate

You start a session with --dangerously-skip-permissions. Every tool call in the parent session runs without prompting. Then the parent spawns a subagent via the Agent tool, and the subagent prompts on every single Edit call. Fourteen edits across eight files, fourteen prompts (#40241).

The bypass flag only applies to the parent session. Subagents start with their own permission state. The reporter tested with hooks both online and offline to rule them out. The behavior is in the permission propagation itself.

Workaround: A PreToolUse hook that returns {"allow": true} would bypass the prompts, but it applies to all users of that hook configuration, not just the session that opted in. There is no clean workaround right now.

What to watch for: If your autonomous pipeline spawns subagents and expects them to run hands-free, they will not. You need to either avoid subagents for write-heavy tasks or accept manual intervention.

Subagents loop and never return

A user asked Claude to explore a 500-line repository using subagents. The explore agent made 106 tool calls, timed out, and never returned a report to the parent (#40230). On a trivially small codebase.

This is a token consumption problem as much as a functionality one. The subagent burns through context without producing output, and the parent waits indefinitely. On a Max plan, the cost compounds quickly.

What to watch for: If you see subagent tool call counts in the double digits for simple tasks, something has gone wrong. Claude Code does not currently impose a tool-call budget on subagents.

Background task notifications silently drop

When you launch multiple Bash commands with run_in_background=true, only the first task’s completion notification is delivered. Tasks two and three complete successfully (their output files exist), but their task_notification messages never arrive (#40235).

The interesting part: Agent tool background tasks work fine in the same scenario. The bug is specific to Bash run_in_background. The reporter discovered this after debugging why a monitoring pipeline was silently losing results.

What to watch for: If you depend on background Bash tasks completing and triggering follow-up work, the parent may never learn they finished. Agent run_in_background is the more reliable path for concurrent work.

Concurrent sessions corrupt shared config

Running two Claude Code instances at the same time can corrupt ~/.claude.json. The file gets partial writes from both, producing invalid JSON. The recovery logic then enters a tight retry loop with no backoff, flooding the terminal with error messages until you kill it (#40226).

This affects anyone running a parent session and a subagent, or two separate terminal sessions. The config file has no file locking.

What to watch for: If Claude Code suddenly starts behaving erratically or printing repeated errors, check whether ~/.claude.json is valid JSON. Kill all sessions, fix the file, and restart.

Phantom messages from teammates

When a teammate agent uses SendMessage to communicate with the orchestrator, the message content can be injected as a Human: turn. The orchestrator then acts on it as if the user typed it (#40166).

The security implication is clear: a subagent can make the parent believe the user gave an instruction. The reporter observed this with Opus 4.6 on 1M context.

What to watch for: If your orchestrator suddenly acts on instructions you did not give, check the conversation history for Human: turns you did not type. These may be SendMessage content from a teammate.

CLAUDE.md stripped from subagents entirely

Starting in v2.1.84, subagents are spawned with omitClaudeMd: true. Your CLAUDE.md rules, constraints, and behavioral directives are not passed to subagents at all (#40459).

This is not a partial loading issue or a context compaction artifact. The flag explicitly tells the subagent to skip CLAUDE.md during initialization. If your security model depends on CLAUDE.md rules like “never modify production configs” or “always use –dry-run first,” those rules exist only in the parent session. Every subagent starts with a blank slate.

The practical implication: PreToolUse hooks are the only enforcement mechanism that survives subagent spawning. Hooks fire on every tool call in every context, including subagents. CLAUDE.md rules do not cross the boundary at all.

What to watch for: If subagents started violating rules that previously held, check your Claude Code version. The omitClaudeMd change was not documented in release notes. The only evidence is the behavior change and the spawning parameters visible in debug output.

The broader pattern

These are not edge cases. They are the current state of multi-agent Claude Code as of v2.1.86. The permission model, the notification system, the config file management, and the message routing all assume a single session. When you add subagents, each assumption breaks in a different way.

If you are building autonomous pipelines on Claude Code:

1. Test subagent behavior separately from parent behavior. Do not assume they inherit anything.
2. Prefer Agent run_in_background over Bash run_in_background for concurrent work.
3. Avoid running multiple Claude Code instances that share ~/.claude.json.
4. Monitor tool call counts. If a subagent passes 50 calls, it is probably looping.
5. Audit conversation history for phantom Human: turns in multi-agent setups.
6. Use PreToolUse hooks for any rule you need enforced in subagents. CLAUDE.md rules do not propagate.

These are all platform-level issues that Anthropic will presumably fix. Until then, know the failure modes so you can design around them.