Subagents Without Context: Claude Code's Silent Bug

Claude Code has a feature that most users don’t consciously notice but relies on heavily: subagents. When the agent needs to run something in parallel, or explore a subproblem without cluttering the main conversation, it spawns a subagent. The subagent does work, returns a result, and goes away.

This is a genuinely useful pattern. It lets the main agent delegate research to a subprocess without derailing the main thread.

It also has a silent bug that nobody talks about, and I only discovered it because I was deep in debugging a memory system that kept losing context across what should have been a single session.

What the bug looks like

I was working in a project with AXME Code loaded. The main agent had full context: glossary, patterns, decisions, safety rules. Everything was working.

I asked the main agent to do a task that internally required delegating to a subagent. The subagent ran, returned a result. I looked at the result and said “that can’t be right, we have a pattern that explicitly says X.”

The main agent looked at me like I was making things up. It said “I don’t see pattern X in the context.” I checked. Pattern X was there, in .axme-code/memory/patterns/, clearly loaded at the start of the session.

Then I realized: the subagent didn’t see it. The subagent had been spawned in a fresh context. It had none of the memories, none of the decisions, none of the safety rules. It did its task, made a call that would have been corrected if it had known the pattern, and returned a wrong answer that the main agent then relayed to me.

The main agent had full context. The subagent had zero context. And unless you inspect exactly which agent is making which decision, you don’t see this happening. It looks like the whole session is running with memory, but half the work is being done in the blind.

Why this happens

Here’s the internal shape. When Claude Code spawns a subagent, it runs in a new process. The new process invokes Claude with a fresh set of messages. The parent process’s context is not automatically forwarded.

If you have a memory system that runs as an MCP plugin or as a pre-tool-use hook, the hook runs in the parent process. The parent process is where your memory file gets loaded and injected into the agent’s messages. Great.

But the subagent is a different process. When the subagent starts, it doesn’t know anything about the parent. It doesn’t run the same MCP plugin, because MCP plugins are per-process. It doesn’t see the parent’s injected context, because that context only exists in the parent’s message history.

The result: subagent runs with default Claude behavior. No memory. No decisions. No safety rules.

You can argue this is by design. A fresh subagent is clean, with no baggage, focused on one task. That’s a reasonable design choice. It breaks when the task is the kind of task that needs context.

The “ppid-walk” fix

The fix I landed on is a trick involving parent process IDs. It is not elegant. It works.

When a subagent starts, it runs a startup hook. That hook does this:

1. Get the current process ID.
2. Walk up the process tree via ppid until it finds a Claude Code session that has .axme-code/ context loaded.
3. Locate the workspace root of that parent.
4. Load the parent’s context into the subagent’s own environment.

In code, the hook looks something like this:

function findParentContext() {
  let pid = process.pid;
  while (pid > 1) {
    const ppid = getParentPid(pid);
    const cwd = getProcessCwd(ppid);
    if (cwd && fs.existsSync(path.join(cwd, '.axme-code'))) {
      return cwd;
    }
    pid = ppid;
  }
  return null;
}

(getParentPid and getProcessCwd are platform-specific. On Linux you read /proc/<pid>/stat and /proc/<pid>/cwd. On macOS you use ps. On Windows it’s different and I have not tested Windows.)

Once the subagent knows where the parent is, it loads the parent’s .axme-code/ directory and uses that context for the rest of its run.

Why this is fragile

Let me list all the ways this fix breaks, because I want to be honest about it.

1. ppid is not always the Claude Code parent. Process trees can get weird. If the subagent is launched inside a shell wrapper, the shell’s pid is the ppid, not Claude’s. You have to keep walking. The walk terminates when you find a process that has .axme-code/ in its cwd, but you’re guessing.

2. cwd detection varies across platforms. The approach I use works on Linux (/proc/<pid>/cwd). On macOS it’s an lsof-based hack. On Windows… I don’t support Windows in this hook, honestly. If you use Windows and this matters to you, I would like to hear how you solved it.

3. The parent might have moved. If the parent Claude Code process started in one directory and then cd’d to another, the cwd at the time the subagent starts might not be where the .axme-code/ actually is. I handle this by looking at the parent’s initial cwd from the stat file rather than current cwd. Edge case.

4. Subagents can be multi-generational. A subagent can spawn its own subagent. The ppid-walk has to handle arbitrary depth. This works, but means you’re walking a potentially long process tree, and any broken link breaks context propagation from that point down.

5. There is no official Claude Code API for this. I’m reverse-engineering. Claude Code could change its subagent behavior in a future version and this trick stops working. I have no insider knowledge of their roadmap.

None of these have broken for me in practice over several months of running this, but I’m aware they could.

Why I still use it

Despite the fragility, the ppid-walk is the only way I know to get context into subagents without modifying Claude Code itself. And the consequence of not doing it (subagents running blind) is worse than the consequence of a fragile hook (occasional context loss that you notice and fix).

The alternative, which is “wait for Claude Code to add an official way to share context with subagents,” is not a solution I can use today. This is.

If you’re rolling your own memory system for Claude Code, I strongly recommend you add this to your list of things to handle. You will hit the subagent-context-loss bug eventually, and it will be subtle, because the parent still works fine and the subagent failure only shows up when you inspect specifics.

What would fix it properly

Claude Code could add:

• An environment variable that points subagents to the parent’s context directory.
• A flag on subagent invocations that says “inherit the parent’s MCP config and pre-tool-use hooks.”
• A shared state store that both parent and subagent processes can read.

Any of these would replace the ppid-walk with something stable. I’d happily delete 200 lines of hack code.

Until then, the hack is the fix. And if you run Claude Code on anything nontrivial, you need the hack.

The one thing to do

If you built your own memory system and you haven’t thought about subagents, go check right now whether your subagents are seeing your context. The test is simple:

1. Start a session with memory loaded.
2. Ask the agent to do a task that you know internally spawns a subagent (any parallel search, any multi-file exploration).
3. Interrupt mid-subagent and ask what the subagent knows about your project.
4. If the answer is “nothing specific,” your subagents are blind.

Most self-built memory systems fail this test. Once you see it, you cannot unsee it.

I wrote the ppid-walk because I noticed the bug and couldn’t find anyone else talking about it. If this post is the first time you are hearing about it, welcome to the club.