TL;DR: I captured two local Claude Code processes with different PIDs and overlapping lifetimes operating under the same session ID. Both were children of the same VS Code extension host process, so the second one was not typed into a terminal. The continuation visible on my PC, reported Done at 21:31. The original continuation kept producing events, returned worker results, and reached a pending Bash permission request at 22:15. Both ran on the PC; my phone only exposed the original process through Remote Control notifications and prompts. Those are not subagents, but different processes.
I'm posting this to find out whether anyone else has seen the same state, particularly with the VS Code integration and Remote Control.
I will use Alice and Bob as aliases to make the chronology readable: Alice is the original local process, and Bob is a second local process launched later with --resume for Alice's session ID.
What the local logs show?
Claude Code stores a session as a JSONL file in which every event points to the one before it through a parentUuid field, so a normal session reads as one straight chain. Subagents don't change that; they write to their own separate transcript files.
At 19:40:27 that chain split. One event ended up with two different direct children:
- At 19:40:32, Alice, the process that had been running since 18:51, continued from it
- At 19:40:43, a second
claude.exe started with --resume=<the same session ID>. Its resume marker points at that same parent event. That second process is Bob.
From that moment on, two live processes were extending the same conversation from the same point.
The two-process conclusion is not an impression from the UI. It rests on:
- two different local PIDs;
- one original command line and one
--resume command line;
- the same Claude Code session ID in both process records;
- both PIDs recorded as children of the same VS Code extension host process;
- two child UUIDs sharing one
parentUuid; and
- overlapping worker activity from both ancestries.
Bob later looked stale, so at 19:53 I typed wts up. He replied and continued normally. The split had already happened around 13 minutes earlier, so that message did not trigger it.
Both ancestries launched workers into the same worktree, and they targeted the same output paths down to the file names. Bob's three workers completed first. When Alice's two workers returned, one reported overwriting output that was already in place, and the other wrote to the same output path again.
At 21:31, Bob's visible continuation reported Done (with the usual "what changed" summary indicating the end of the work). At that moment Alice's two workers were still mid-run (but invisible to me as the UI did not show any messages or prompts or thinking indicators). Everything was quiet for roughly 20 minutes.
Alice did not end there. Her two original workers returned at approximately 21:50 and 22:01. She then asked about another run ( which I approved through Remote Control), and reached a Bash permission prompt at 22:15 (By then I stopped approving and started looking into the issue).
At the final evidence capture at 22:53, both OS processes were still alive and responsive. That includes Bob's PID, so Done should be read as Bob's final response, not as proof that his process exited. When I rechecked the today, both processes were still alive, the transcript hash was unchanged, and Alice's Bash permission request was still pending (because I did not answere it!).
Both executions ran locally on the PC; the phone ran nothing. Bob was the one open in the vs code view I was using. Alice and her prompts were not, so her activity surfaced as Remote Control notifications on my phone, which is what made me investigate (I did keep the process running by approving request after I noticed the problem as I wanted more data to investigate).
What is documented, what is strange?
Anthropic's session documentation says that if the same session is resumed in two terminals without forking, messages from both processes interleave into one transcript, and that an intentional /branch or --fork-session gets a new session ID. So I am not claiming that one transcript receiving messages from two deliberately resumed processes is undocumented.
What I cannot explain though:
- What made the VS Code extension host start a second
--resume process while Alice was still alive? and Why was Alice difficult to discover in the desktop UI?
- Why could Bob appear finished while Alice still had running workers, tool activity, and later a permission request under the same session identity?
- At 22:15:30, Alice created her Bash permission request. Eleven milliseconds later, the extension sent that request to my phone through Remote Control. One millisecond after that, the desktop chat panel reported the very same session as
idle with hasPendingPermissions: false. How can one session have a permission in flight to my phone and nothing pending on the desktop at the same instant?
That last point may indicate same-ID UI state masking one execution with the state of the other, but that is just me guessing.
On the first point, the process tree rules out a resume typed into a terminal, but the extension host log had rotated past the 19:40 spawn moment, so the triggering action is not in the retained logs. What remains is either an automatic extension lifecycle or reconnect action, or something I did in the extension or through Remote Control without realizing it would spawn a second process (but I really doubt it as the task was a basic linear implementation one with no complexe workflows). I do not have enough evidence to pick one, or to label this a confirmed product bug.
The most concerning part is not the graph shape by itself. It is the ownership ambiguity from a user perspective: A session that appeared finished still had a difficult-to-discover sibling execution capable of accessing the same worktree and requesting permission. Fortunately, I use manual validation for most of my sessions, I cannot imagine how "not okay" this situation would be if I used auto approve for that session.
That creates several risks:
- two divergent contexts can write the same files;
- a permission prompt may belong to an execution the user cannot currently see;
- a linear history can obscure which ancestry produced a tool call or file;
- duplicated workers can consume resources while appearing to be one logical task.
- The actual work is done twice! Actually 33% of the token spent was due to the fork.
Setup and methodology
Environment: Windows 11, Claude Code 2.1.211 through the VS Code extension, Remote Control enabled. All times are 21 July 2026, CEST.
I reconstructed the event trace and execution overlap with a tool I've been maintaining for a while now CheckYourAgent and asked both Fable and Sol to tap into the tool API to do the investigation work. CYA mainly served as a way for me to validate the findings as it is data viz centric and to compute the cost data.