[BUG] send_message reports success on native Windows where cross-session messaging is not offered — no inbox socket bound, nothing delivered, caller cannot tell (worked on this machine until 2026-08-11)

Supersedes and extends our earlier report our earlier internal report (2026-08-13). What is new here: the queue mechanism itself, measured on both sides of the regression, plus a correction to that earlier report's claim that the payload is stored encoded. It is stored in plaintext, which makes this cheaply greppable and changes how it should be triaged.

---

1 · Summary

send_message (cross-session) returns a success string naming the correct target. On the target:

1. the session wakes — isRunning flips false → true and lastActivityAt advances to the send instant;
2. it runs for roughly 1–2 seconds;
3. no queue-operation record is written, the transcript does not grow, and no turn is produced;
4. the session is left isRunning: true and does not recover on its own.

The distinguishing measurement in this report: when this feature worked, delivery wrote a
queue-operation / operation:"enqueue" record carrying the message body in plaintext, immediately
followed by a dequeue. In the broken state that enqueue record is simply never written. The wake-up
still happens, so the notification path is intact and the enqueue/persist path is what fails.

---

2 · Environment

| | |
|---|---|
| OS | Windows 11 Home, 10.0.26200 (build reported by the shell as 10.0.26200.9168) |
| App | Claude, MSIX / Store install |
| Version tested (still broken) | 1.30096.1.0 — PackageFullName: Claude_1.30096.1.0_x64__pzs8sxrjxfjjc |
| Package write time | 2026-08-14 12:22:58 +0800 (this build was installed ~35 min before the probe below) |
| Version implicated in the regression | 1.28929.0 (per #86069; its changelog covers "failing to save chat history, settings, and scheduled tasks") |
| Sessions involved | Ordinary local interactive sessions, same project directory. Neither is a scheduled task, remote dispatch, or worktree session. |
| Target state at send | Idle and finished — last activity 3 days earlier |

⚠ This is still broken on 1.30096.1.0. The August cross-session fix we can find in the release
notes addresses *"messaging sometimes starting without an inbox in the first session after install or
upgrade"*, which is a different symptom.

---

3 · The mechanism, measured on both sides — this is the part we think is new

3.1 · WORKING (before the regression)

A delivered prompt is written to the target's transcript .jsonl as a queue operation with the body
in plaintext, then dequeued ~200 ms later:

{"type":"queue-operation","operation":"enqueue","timestamp":"2026-08-11T21:56:39.525Z",
 "sessionId":"<session-B-uuid>",
 "content":"<session B's first prompt text>"}
{"type":"queue-operation","operation":"dequeue","timestamp":"2026-08-11T21:56:39.747Z",
 "sessionId":"<session-B-uuid>"}

And the same shape holds for a genuine cross-session delivery, including the From {sender title}
envelope the feature adds:

{"type":"queue-operation","operation":"enqueue","timestamp":"2026-07-25T14:56:30.351Z",
 "sessionId":"<session-uuid>",
 "content":"From <sender session title> \n\n\n<message body, stored verbatim and unencoded>"}

3.2 · BROKEN (now)

Same target session, same machine, probe at 2026-08-14T04:57:36Z:

• send_message → Message sent to session local_<session-B-id> ("Session B")
• get_session → isRunning: true, lastActivityAt: "2026-08-14T04:57:36.230Z" (was 2026-08-11T21:56Z)
• target transcript: 10 lines before, 10 lines after
• records dated 2026-08-14 in the target transcript: 0
• queue-operation records dated today: 0 — no enqueue, no dequeue
• transcript file mtime advances to 12:57:37 +0800 (= the send instant) while gaining no records
• .claude.json and its backup written at the same second — neither contains the payload

⇒ The session is woken and something rewrites state, but the prompt is never enqueued.

---

4 · Reproduction

1. Session A and session B, both ordinary local interactive sessions. Leave B idle and finished.
2. From A, call send_message at B with a unique marker string in the body.
3. Read the tool's return value. (It will claim success.)
4. get_session(B) → observe isRunning: true and lastActivityAt at the send instant.
5. Grep B's transcript .jsonl for queue-operation, and for the marker.

Expected: an enqueue record containing the marker, then a dequeue, then a turn.
Actual: neither record appears; the transcript does not grow; B stays isRunning: true indefinitely.

---

5 · Controls we ran, so the negatives are trustworthy

| control | result | what it rules out |
|---|---|---|
| Grep the marker across all transcripts | found only in the sender's own transcript | the sender writes what it sends; a naive all-sessions grep produces a false positive |
| Same grep excluding the sender's file | 0 | the payload really is absent at the destination |
| Grep a string known to be in B's transcript ("<session B first prompt>") | found | the grep is not blind to that file |
| Grep the marker in base64 and UTF-16LE | 0 | not an encoding artefact |
| Search the entire .claude tree, plus .claude.json and its send-time backup | 0 | not stashed in a side store we know of |
| Count same-day records in a session that did receive a prompt that day | 80 | the "0 records today" reading is real, not a query fault |

⚠ Note for triage — one of our own earlier conclusions was wrong and may be echoed elsewhere. Our
first report stated the payload is *"stored encoded, so a marker grep reads 0 for never-arrived AND for
arrived-and-working."* That is refuted by §3.1: the content is plaintext in the enqueue record. A
plaintext grep is a valid instrument here, and 0 genuinely means never enqueued.

---

6 · Regression window

| when (local +0800) | event |
|---|---|
| 2026-08-11 21:56 | queue enqueue/dequeue working (§3.1) |
| night of 2026-08-11 | a cross-session message is received normally by another session |
| 2026-08-12 06:47 | .claude/settings.json rewritten |
| 2026-08-12 06:48 | break time reported independently in #86069 (18:48 ET) |
| 2026-08-12 14:08 | our workflow switches to a file-based workaround — the send route has already failed |
| 2026-08-14 04:57Z | still failing on 1.30096.1.0 |

The settings.json rewrite one minute before the reported break is suggestive given that
1.28929.0 was itself a settings/history persistence change. We are not claiming causation — we
report it because the file's contents are unremarkable (see §7) and only its write time is notable.

---

7 · What we ruled out locally

• Our own config. settings.json explicitly permits mcp__ccd_session_mgmt. Both configured hooks

are PreToolUse matching Agent and Bash|Write|Edit — neither matches the messaging tool.

• A third-party CLI install. Unrelated tooling was installed on this machine at 2026-08-12 19:16,

more than five hours after the failure was already measured. Timeline excludes it.

• Machine-specific cause. #86069 reports the same symptom on a different machine beginning the same

day, which no local install of ours could affect.

• A broken deploy of the app itself. The session wakes on cue, so IPC/notification is alive.

---

8 · Relationship to existing issues

• #86069 — Windows/MSIX, reports success, target never responds. Closest. It states the message

is written as a last-prompt record and appears in the composer. We cannot reproduce that half: we
see no record written anywhere. Either two failure modes share a symptom, or the composer copy lives
somewhere our filesystem search does not reach (we could not inspect the running UI).

• #84945 — inbox socket fails to bind for one of two identical sessions. **A socket that never

binds would explain "wakes but never enqueues" exactly.** We suggest checking these together.

• #86319 — delivered to transcript but never processed. Not us — nothing is delivered.
• #86014 / #86370 — success reported, never delivered. Same first half; neither records the

permanent isRunning: true.

• #86279 / #86138 — hung/phantom turn. Closest on the wedge, filed without the transcript measurement.

A discriminator triage can use cheaply: *does a queue-operation:"enqueue" record appear in the
target's .jsonl?* It separates not delivered from delivered and stuck in one grep.

---

9 · Impact

• The failure is silent in the worst direction: the sender is told it succeeded. Any multi-session

workflow will record a handoff that never happened.

• Each probe costs a session — the target is left wedged isRunning: true and has to be abandoned

and recreated. That makes re-testing after each release expensive.

• Our workaround requires a human in the loop on every handoff: write the payload to a file, and have

a person paste one line into the target chat. It works 100% of the time, which further localises the
fault to the delivery/enqueue path rather than to the target session's health.

---

10 · Suggested diagnostics

1. Instrument the path between "send accepted" and "enqueue written". **The wake fires and the enqueue

does not**, so the failure is between them.

1. Check whether the enqueue write is attempted and silently fails under **MSIX/AppContainer file

virtualization** — 1.28929.0 changed persistence, and this app's %LOCALAPPDATA% view differs
between the packaged app and an ordinary user shell on this machine.

1. Make send_message report the destination-side result rather than acknowledging the request.

Today's success string is indistinguishable from a total delivery failure.

1. Ensure a woken session that finds nothing to dequeue returns to idle instead of remaining

isRunning: true forever.

---

11 · What we could NOT check — stated so nobody assumes it was covered

1. ⛔ We could not inspect the running UI. #86069's central claim is that the message *appears in the

target's input composer*. Every measurement above is filesystem-side. If the composer holds a copy
that is never persisted, our "no record written" finding and #86069's "written as a last-prompt
record" are both true of different layers — and that would make the composer the only place the
payload exists. A user with the window open can settle this in one look; we could not.

1. ⛔ We did not identify what rewrites the target's transcript file at the send instant. Its mtime

advances while its record count does not change. Something opens and writes that file and adds
nothing — that write is probably the cheapest place to attach a breakpoint.

1. ⛔ We could not read the packaged app's own view of %LOCALAPPDATA%. On this machine the MSIX

app's AppData is virtualized and is not the same view an ordinary user shell sees, so a store we
searched and found empty may not be the store the app actually wrote to. This is the single most
likely way our negative results could be wrong, and it is also why suggestion §10.2 is our lead
hypothesis rather than a conclusion.

1. ⛔ We have exactly one confirmed cross-session delivery example on disk (2026-07-25) carrying the

From {sender title} envelope. We did not establish that every delivery is serialised identically, so
§3.1 should be read as "this is how at least one real delivery was stored" rather than as a schema.

---

Reported by: a user running two long-lived local sessions in one project directory.
Everything above is measured on this machine at 1.30096.1.0; command outputs available on request.

💬 Message from <sender session title>
PING-…-0457 — connectivity test only, from <sender>.
⛔ THIS IS NOT A PROMPT AND THERE IS NO WORK ATTACHED. Do nothing. …

2026-08-11 21:56:39   last observed WORKING enqueue/dequeue pair in a target transcript
2026-08-12 06:33:12   1.28929.0.0 first deployed on this machine
2026-08-12 06:47      ~/.claude/settings.json rewritten
2026-08-12 06:48      break time independently reported in #86069 (18:48 ET)
2026-08-12 14:08      this user's workflow had already switched to a manual workaround
2026-08-14 05:37      still failing on 1.30096.1.0

CLAUDE_CODE_MESSAGING_SOCKET = <UNSET>
CLAUDE_CODE_MESSAGING_TOKEN  = <UNSET>

Message sent to session local_… ("<target title>")