Regression: starting a second local Code session SIGTERMs the first one (desktop 1.32352.1)

Summary

In the Claude desktop app, only one local Code session can stay alive. Starting a second
session terminates the already-running session's CLI process with SIGTERM (exit 143),
typically within 0 to 5 seconds. The user sees a generic "Session was interrupted / Try
sending your message again" in the session that was killed, with no indication that another
session displaced it. Retrying then kills the other one, so two sessions ping-pong and
neither can be used.

This is a regression. Across six log files there are zero such kills before 2026-08-13,
including a day with 25 session starts and no kills at all.

Environment

| | |
|---|---|
| Claude desktop app | 1.32352.1 |
| Bundled claude-code | 2.1.229 (~/Library/Application Support/Claude/claude-code/2.1.229/) |
| macOS | 26.6.1 (build 25G76), Darwin 25.6.0 |
| Hardware | Apple Silicon, 16 GB RAM |

Reproduction

1. Open a local Code session (pane A).
2. Open a second local Code session in a split pane (pane B).
3. Send a message in either pane.

The other pane's CLI process is killed a few seconds later and shows "Session was
interrupted".

Concrete instance, ~/Library/Logs/Claude/main.log:

22:03:16 sendMessage: sessionId=local_8bde5aac…                     ← pane B
22:03:16 [CCD] sendMessage on uninitialized session local_8bde5aac…; cold-starting via startSession
22:03:16 Starting local session local_8bde5aac… in /Users/wuwanqiang/Downloads
22:03:21 Starting local session local_cb0c9b06… in /Users/wuwanqiang/Downloads   ← pane A starts
22:03:24 [error] Session local_8bde5aac… query error: Claude Code process exited with code 143

Pane A starting at 22:03:21 is followed by pane B dying at 22:03:24. The same pattern occurs
a minute earlier: pane B warms at 22:02:18, pane A dies at 22:02:21.

ps during the repro shows exactly one
claude-code/2.1.229/claude.app/Contents/MacOS/claude --output-format process, never two.
Exit 143 is 128 + SIGTERM, so the process is terminated deliberately rather than crashing.

Evidence that a session start is the trigger

Across all six main*.log files: 59 exit-143 kills, 4270 memory-pressure warnings, 577
session starts. Correlating each kill against events belonging to a different session id:

| window | kill has a memory-pressure warning nearby | kill has another session starting nearby |
|---|---|---|
| ±30 s | 2 / 59 (3.4%) | 44 / 59 (74.6%) |
| ±60 s | 6 / 59 (10.2%) | 46 / 59 (78.0%) |

The lag between the other session's start and the kill is tightly clustered, which is what
rules out coincidence. Of the 37 kills with an identifiable preceding start:

lag  0s ####
lag  1s #####
lag  2s #######
lag  3s ########
lag  4s #####
lag  5s ###
     (32 of 37 within 0-5 s; remainder scattered at 8, 12, 15, 16, 41 s)

Memory pressure is not the cause

[CliGovernor] memory pressure is the obvious suspect and it is wrong. Of 4270
memory-pressure warnings, only 4 (0.1%) are followed by a kill within 60 s. The warning
fires constantly on this machine and almost never kills anything. The 1 effective figure
in that warning line is a red herring.

Not scoped to a shared working directory

75% of kills are between two sessions in different directories, so this is not a
same-cwd conflict. Example pair: ~/Desktop/项目申请/27年省自科 and ~/Downloads.

Regression window

Kills by day, against session starts on the same day as a control:

| date | exit-143 kills | session starts |
|---|---|---|
| …2026-08-11 | 0 | 25 |
| 2026-08-12 | 0 | 8 |
| 2026-08-13 | 5 | 4 |
| 2026-08-14 | 12 | 4 |
| 2026-08-15 | 10 | 5 |
| 2026-08-16 | 22 | 6 |
| 2026-08-17 | 3 | 3 |
| 2026-08-18 | 7 | 4 |

Heavy use before 2026-08-13 produced no kills at all; lighter use after produced many. The
bundled claude-code version in use over the same period, from
Using Claude Code binary at lines:

2.1.219   2026-07-27 → 2026-08-05
2.1.221   2026-08-05 → 2026-08-07
2.1.222   2026-08-07 → 2026-08-12 15:41     last version with zero kills
2.1.227   2026-08-12 16:24 → 2026-08-13     kills begin
2.1.229   2026-08-14 → present              still reproducing

The change landed between 2.1.222 and 2.1.227.

Expected

• Two local sessions coexist. This worked before 2026-08-13 and is the main reason to use

split panes at all.

• If a concurrency cap is genuinely intended, say so before the second pane opens rather

than terminating a running session mid-turn.

• If a session is terminated deliberately, name the cause. "Session was interrupted / Try

sending your message again" reads as a transient network failure and invites a retry that
cannot succeed, since the retry kills the other session instead.

Note on an earlier misreading

An earlier draft of this report claimed messages were being cross-delivered between
sessions, because the same prompt appeared in both panes. Checking the screen recording
frame by frame showed the prompt sitting in the second pane's composer before submission,
so the user had entered it in both panes deliberately. There is no evidence of message
misrouting and that claim is withdrawn. The displacement behavior above is unaffected.

Secondary observation

Possibly unrelated, logged in the same window: a cloud session failed its transport
connection with a 403.

22:02:21 [error] [sessions-bridge] Failed to connect transport for session cse_014kQNYtrSBTMdPntiMnbwb5: Request failed with status code 403

A screen recording of the reproduction is attached in a follow-up comment.