[BUG] Cross-session send_message reports success but message is never delivered (stuck loading, 0/4 delivery)

Confirming — same regression, with log forensics pinning it to the 1.28929.0 desktop rollout.

Environment: macOS (arm64), Claude Desktop 1.26832.0 → 1.28929.0 (staged ~19:06 Aug 11, activated on relaunch 08:46 Aug 12, +04), embedded Claude Code 2.1.222 → 2.1.227. Multiple concurrent local sessions, heavy cross-session SendMessage use.

Before/after from ~/Library/Logs/Claude/main.log:

• Under 1.26832.0 (Aug 11): 210 cross-session deliveries, 197 fully processed (mapping → stop hook → healthy cycle).
• Under 1.28929.0 (Aug 12, post-08:46): 59 deliveries, 45 processed — failures now include idle sessions failing on their first inbound message.

Cleanest single repro from the logs (session local_8b4ac8e0…):

1. 10:36:41 LocalSessions.sendMessage … messageLength=25 (user-typed message) → mapping → 10:36:50 [Stop hook] Query completed → 10:36:54 [CCD CycleHealth] healthy cycle (13s) — session healthy.
2. 10:37:26 Sending message to session local_8b4ac8e0… (cross-session send) → nothing: no CLI-session mapping, no transcript append, no error, no process exit. Session shows a permanent grey/pending state; subsequent typed messages queue and never run.

No EPIPE/ENOENT/spawn/IPC errors at any delivery moment. The receiving process stays alive. Sender sessions keep working and get a success result. Possibly related to #85714 (peer messages queueing silently behind a blocking dialog) — we saw a low rate of that shape on 1.26832.0, but 1.28929.0 made first-message-kills-idle-session the common case.

Happy to provide fuller log excerpts.

Also saw this. My write up:
Using mcp__ccd_session_mgmt__send_message to send a message from one active session to another (both local, non-remote), the message appears in the recipient's UI as a "Message from X" card, and the tool call itself reports success ("Message sent"/"Message queued"). However, the recipient session never actually processes it as a turn — no "thinking..." indicator ever appears, only a timer that counts up indefinitely with no progress. The sending session also never receives a reply, since the recipient never actually runs.

Reproduced twice in the same working session: once with an inbound message (another session → mine), once outbound (mine → another session) immediately after. A client restart did not clear the stuck state on a subsequent attempt.

This affects any workflow built on sequential cross-session messaging (e.g., broadcasting a message to several sessions one at a time, waiting for each reply before advancing) — one silent delivery failure anywhere in the chain stalls everything downstream with no error or timeout surfaced to either party.

Seeing this too - I've seen failures since updating the desktop app last night (on Windows). All the message sends this morning between top-level sessions have been failures (throbber but no response on the recipient side), but messages between a top-level session and its subagents appear to be working so far.

#86067 looks very similar / the same

possible dupe of #86012

Update: downgraded the desktop app to 2.1.227 (via the official install script) and retested — cross-session send_message still fails the same way (sender gets success, recipient shows perpetual loading, nothing delivered). So this does not appear to be a client-side regression from the 2.1.228 build alone; the delivery path looks broken server-side (or in a component that isn't rolled back by downgrading the client). Timeline still matches: everything worked before the desktop update wave last night, broken since, on both 2.1.228 and now 2.1.227.

Your 0/4 delivery matches exactly — #86298 documents the same failure chain with root-cause analysis (Windows desktop, regression at app 1.28929.0 / bundled CLI 2.1.227, still present on app 1.30096.1.0 / CLI 2.1.229): the desktop bridge sends the message with a class-less origin:{kind:'peer'}, the recipient CLI/SDK's cross-session consent gate holds it for an approval no desktop surface offers, and dialogExpiry (~5 min) then drops it — while the sender keeps a success receipt. A memory-dump repro in that thread shows the payload reaching the recipient CLI process but never its transcript. Setting crossSessionInbound: "accept" in user settings does not unblock it (tested on running, cold-started, and post-restart fresh sessions).

Same issue, model calls ccd_session_mgmt: send message tool. New message appears in the other chat but, no thinking, no processing, just an indefinite timer.

Confirming this on Claude Code Desktop, Windows 11 (10.0.26200) — same environment as the original report. Adding observations that aren't in the thread yet, in case they help narrow it down.

The receiving session never gets the message into model context — confirmed directly, not inferred.

After a stuck delivery aborted, I typed this by hand into the target session:

1. Is this chat working normally? 2. Do you see an orchestrator assignment above this message about a handwriting measurement? If yes, name the first of the two misspelled words in it.

Answer: "1. Yes, the chat is working normally. 2. No — there is no orchestrator assignment above, so no misspelled words I could name."

The message was visible on screen the whole time. So the session is healthy and the message is rendered, but the model never receives it.

Rendering differs from #86069. There the text stays in the target's composer and is never submitted. Here it appears as an already-submitted prompt in the chat body — not editable, not re-submittable. The only recovery is to select the text, copy it, and send it again manually. Possibly the same root cause, but the surface behaviour is different and worth distinguishing.

No transcript write during the stuck period. The target session's JSONL file was byte-identical across the hang (115,822,652 bytes at 08:21:34, same size at 08:29:29), while the sending session's file kept growing normally. Consistent with "no turn was ever created" rather than "turn ran and output was dropped".

Abort behaviour: the spinner runs 10–15 minutes, then stops. An error icon appears next to the session in the sidebar, but no error text appears in the chat window. Nothing tells the user what happened.

One partial delivery. In one case the target session reported on its own that only the header and first section had arrived and that three further sections were missing. So it is not always all-or-nothing.

Sender always sees success. Message sent to session ... in every failing case. In one case Message queued; it will be processed after the in-flight turn finishes — that one was never processed either.

Ruled out on my side:

• Message length — the two longest messages were delivered, the shortest was not.
• Receiver context pressure — retested immediately after compacting the receiving session, same failure.
• Receiver health — hand-typed messages in the same session work instantly.
• Configuration — no crossSessionInbound, dialogExpiry or comparable key in any settings file.
• Service incident — the 16 Aug incident ran 21:58–22:34 UTC; my failures were 15:50–18:00 UTC and continued the next day.

Hit rate: 6 of 10 deliveries failed, across 6 different target sessions, with no pattern I could find in length, idle/busy state, or receiver size.

Regression window matches. Cross-session delivery worked reliably for me on 6–7 Aug (dozens of messages across ~15 sessions). It was broken by 16 Aug. That is consistent with the 11–12 Aug regression date in this thread.

Why this one bites harder than a normal delivery bug: the sender is told it succeeded and the receiver displays the message, so nothing anywhere indicates failure. In a multi-session setup, assignments silently do not happen and the coordinating session believes they are in progress. A delivery failure that reported an error would cost minutes; this one cost a working day.

The message was visible on screen the whole time. So the session is healthy and the message is rendered, but the model never receives it. Rendering differs from #86069. There the text stays in the target's composer and is never submitted. Here it appears as an already-submitted prompt in the chat body — not editable, not re-submittable. The only recovery is to select the text, copy it, and send it again manually. Possibly the same root cause, but the surface behaviour is different and worth distinguishing.

bro that doesnt differ... for all of us we were seeing the "Sent from X session" message box with the full message in the receiver... my sessions also acknowledged from screenshots that the sent message doesnt even appear in the transcript. if u kept sending messages from one session to another and tried to stop it, the harness would even break and not let you click the STOP button, and any message from that breaking point even from the user would get eaten (which if u restarted the app/harness those messages and the full "sent from X session" message block would just dissapear from the UI.)

Additional case — reproduces on latest build, including a controlled test with a live sender and idle receiver

Environment: Windows 11 Home (10.0.26200), Claude Code desktop app, updated to the latest available build on the morning of 2026-08-16 (so ≥ v2.1.232). Multiple concurrent sessions in the same workspace/cwd, same app instance.

Symptom (matches OP): mcp__ccd_session_mgmt__send_message returns Message sent to session <id> ("<title>") but the message is never delivered to the target session. For us delivery was intermittent/unreliable before ~2026-08-14 and has been a total failure since (0 delivered across all attempts, every one reporting success).

Controlled test (2026-08-16 ~23:35 CEST), designed to rule out the "receiver has no turns" explanation:

• Sender: an active session kept alive with a background monitor emitting an event every 30 minutes (so the session had regular turns before and after the send, over 2+ hours).
• Receiver: an idle-but-open session in the same cwd (visible in list_sessions with isRunning: false), deliberately parked in a standby state, user watching its window the whole time.
• Result: send_message reported success immediately. The receiver never displayed the message and was never woken with a new turn. No reply ever arrived at the sender across all subsequent turns. The user (physically watching both windows) confirms zero delivery in either direction.

What still works: list_sessions and transcript search behave normally; only delivery is broken. Messages "sent" are silently lost — there is no error, no queue visibility, no expiry notice.

Note on docs: the cross-session messaging docs state the feature is unavailable on native Windows. If that is the intended state, the bug is that the tool is exposed on Windows and reports success instead of failing loudly — silent data loss is worse than an honest error. If Windows is meant to be supported, delivery has been fully broken since ~2026-08-14 in our environment.

Happy to provide timestamps or run a diagnostic build if useful.

Three follow-ups, one of them a correction of my own comment above.

1. Retracting my distinction from #86069. @TomerBrosh is right — the rendering does not differ. I compared our surface behaviour against the title of #86069 rather than against the reports in it. Same case, and I should not have split it.

2. This is a regression, not an unsupported path — and I can date it.

To be precise about the environment: this is the Claude Code desktop app on Windows 11 — not the terminal CLI, and not Cowork. I can't speak to those.

That distinction matters, because the "not available on native Windows" line in the docs describes the CLI feature (SendMessage / ListAgents, v2.1.224+). The tool failing here is a different one: mcp__ccd_session_mgmt__send_message, exposed by the desktop app's session-management MCP server. Different tool name, different surface, and I have not been able to find any documentation for it at all — no beta flag, no stated platform limits, no delivery guarantees. So the CLI's platform note should not be read as evidence that this channel was never meant to work here.

On my machine (Windows 11, 10.0.26200) that channel worked reliably from 28 July to 7 August: dozens of messages across ~15 concurrent sessions, in both directions. It worked well enough that we wrote a documented workflow around it on 28 July, including the rule that a delivered message starts work in the target session — which we only formulated because target sessions had already completed delivered assignments before the user opened them.

Being precise about the window, because I can't narrow it further: I did not use the app at all between 8 and 15 August, so I can't say when it broke. What I can say is that it worked through 7 August, that I installed an app update on 16 August, and that it has failed on every attempt since. The update is a candidate trigger, not a demonstrated one — I did not test delivery on 16 August before updating.

Either way, a working state on native Windows is documented rather than hypothetical.

Versions here: app (MSIX) 1.30096.5.0, bundled CLI 2.1.220.

Two things worth noting from that. First, #86069 reports MSIX 1.28929.0 — mine is newer, so the bug spans at least two app builds and is not fixed in 1.30096.5.0. Second, the bundled CLI is 2.1.220, i.e. below the 2.1.224 in which the documented CLI cross-session feature was introduced. That further supports treating this as a separate channel rather than the CLI feature leaking onto an unsupported platform.

3. The sharpest evidence I have: both states coexist in the same session's history.

Messages delivered before the regression are still present in the target sessions today — full history, unchanged, weeks later. Messages delivered since the regression behave differently:

• they render in the chat body as an apparently-submitted prompt, with a spinner
• they produce no transcript entry (target session's JSONL byte-identical across a 15-minute hang, while the sender's file kept growing)
• the model never receives them — asked by hand immediately afterwards, the target session states there is no such message above, while it is visible on screen
• when the session is reopened later, they are gone from the UI entirely

So the same session contains persistent entries from the working period and vanishing UI-only renders from the broken period. Whatever changed, it is the step that turns a delivered message into a transcript entry and a turn — the render path still works, the commit path does not.

Practical note for anyone hitting this: per @TomerBrosh's warning, do not keep retrying. Repeated sends can wedge the harness to the point where the STOP button stops responding and subsequently user-typed messages are eaten too. Reading the target session's transcript directly (list_events) works reliably and is a usable substitute for a delivery receipt — but note it proves completion, not delivery: a hung turn leaves nothing there, so an absent message can mean "delivered and stuck" rather than "never arrived".

Follow-up with what I think is the decisive detail, plus a retraction of my own argument above.

/list-agents is not available in this environment. The docs make that a definitive result:

/list-agents isn't recognized: the session doesn't have cross-session messaging.

Alongside that:

• ListAgents is not present in the tool set at all. The documented flow is ListAgents to discover reachable sessions plus SendMessage addressing them by name.
• Bundled CLI is 2.1.220; cross-session messaging requires 2.1.224 or later.
• The docs state the feature is "available on macOS and Linux… Claude Code doesn't offer cross-session messaging on native Windows."

So mcp__ccd_session_mgmt__send_message is not the documented cross-session feature. It is a separate channel exposed by the Claude Code desktop app's session-management MCP server, for which I have not found any documentation — no platform note, no limits, no delivery guarantees. It worked reliably here from 28 July to 7 August across ~15 sessions, and has been broken since.

Retracting my own argument. Earlier in this thread I disputed @Giangi-82's point that the real bug is the tool being exposed on Windows while reporting success. My objection was that the channel demonstrably worked for ten days. That objection was beside the point: it shows an unintended path worked for a while, not that it was supported. Both are true — it worked, and it was never the documented feature. The framing that holds is theirs: silent data loss is worse than an honest error.

Plain-text test: negative. The docs limit the channel to "plain text only", and every message I had sent was dense Markdown — tables, headings, code fences, emoji. I sent one containing no special characters at all. Same result: rendered in the target session, spinner running, never processed. Message content is excluded as a cause.

Everything I have been able to exclude, across ~19 deliveries and four different senders, with exactly one demonstrably processed:

• message length — the two longest arrived, the shortest did not
• message formatting — plain text fails identically to Markdown
• receiver context pressure — retested immediately after compacting the receiver
• receiver session age — a session created the day of the update has the same hit rate as one from May
• sender identity — a delivery between two sessions not involving the orchestrator failed too
• sent vs queued — three of four failures reported sent
• receiver health — hand-typed messages work instantly in the same session
• app restart — full quit and relaunch changes nothing
• local configuration — no crossSessionInbound, dialogExpiry, permissions.deny, no managed-settings file; the auto-mode policy that exists covers file deletion and specific production hosts only, and that classifier announces its refusals rather than hanging

Two operational notes for anyone else coordinating multiple sessions this way:

Repeated sends can wedge the target session to the point where hand-typed messages also hang there — pressing stop released it once out of three attempts. And a transcript search is not a delivery check: a hung turn writes nothing, so an absent message means "not processed", which is not the same as "not delivered".

What this cost in practice, in case it helps prioritise: on one day, five sessions each reported completed work back to a coordinating session. None of the five arrived, and all five believed they had reported. The coordinating session only found out by reading their transcripts directly. A delivery failure that surfaced an error would have cost minutes.

Suas sessões do Claude Code pararam de conversar entre si em 12/08? Achei a causa e o conserto de uma linha

Se você usa várias sessões do Claude Code em paralelo, com uma orquestrando e as outras
executando, talvez tenha notado algo estranho a partir de 12 de agosto: as sessões mandam
mensagem umas para as outras, a ferramenta responde "Message sent", e nada acontece do outro
lado. Passei um dia inteiro caçando isso, errei o diagnóstico três vezes, e no fim o conserto
foi uma linha de configuração. Escrevo aqui o caminho todo, inclusive os becos sem saída, porque
foram eles que mais me custaram tempo.

O cenário

Doze sessões abertas no mesmo projeto, no aplicativo de desktop do Claude Code em macOS. Uma
sessão orquestradora e as demais especializadas, cada uma com o seu papel. Elas se coordenam
mandando mensagem direto na janela uma da outra, sem eu ficar copiando e colando. Funcionou
muito bem por três semanas.

O sintoma

Do lado de quem envia, sucesso. A ferramenta devolve literalmente:

Message sent to session local_xxxxxxxx ("NOME DA SESSÃO")

Do lado de quem recebe, nada. Nenhum "pensando", nenhum turno novo, nenhuma linha no histórico.
Em alguns casos aparece um cartão de mensagem na tela do destinatário com um cronômetro subindo
para sempre.

O pior é que isso é invisível para quem enviou. A orquestradora planeja em cima de "entreguei",
o destinatário nunca soube de nada, e ninguém é avisado para tentar de novo.

As três pistas falsas que me custaram horas

Vale mais contar os erros do que o acerto, porque provavelmente você vai cair nos mesmos.

Primeira: achei que o endereço estava morto. Listei as sessões procurando o nome da minha
própria orquestradora e não encontrei. Conclusão óbvia e errada: o nome não existe, por isso as
respostas se perdem. Acontece que a listagem de sessões não inclui a sessão que pediu a
listagem. Eu estava procurando a mim mesmo. Além disso, a listagem tinha me devolvido 120
sessões enquanto o disco guardava 188, então "não achei" nunca valia como "não existe".

Segunda: achei que os agentes tinham acordado. Mandei mensagem, olhei a lista de sessões, e
lá estavam elas marcadas como rodando, com atividade de segundos atrás. Ótimo, pensei, estão
trabalhando. Não estavam. O campo de última atividade é atualizado pela mensagem que não foi
entregue. Uma sessão morta há três dias fica com cara de recém-ativa. Fui conferir os históricos
e nenhum tinha andado.

Terceira: achei que era janela fechada. Faz sentido, mensagem para janela fechada se perde.
Só que encontrei um caso em que a janela de destino estava aberta e em uso, com turnos antes e
depois do horário do envio, e a mensagem também sumiu. Não era isso.

Como investigar de verdade: está tudo em disco

Essa foi a virada. Parei de acreditar em indicador de tela e fui ler arquivo. Em macOS são três
lugares.

1. O histórico de cada sessão

~/.claude/projects/<pasta-do-projeto>/<cliSessionId>.jsonl

Uma mensagem entregue vira uma linha de tipo user cujo conteúdo começa com:

<cross-session-message from="local_..." name="NOME DO REMETENTE" encoded="1">

Essa marca é a prova. Se ela não está lá, a mensagem não chegou, ponto final, não importa o que
a tela diga. Para contar quantas cada sessão recebeu e quando foi a última:

cd ~/.claude/projects/<sua-pasta>
for f in *.jsonl; do
  n=$(grep -c "cross-session-message" "$f")
  [ "$n" != "0" ] && echo "$n  $f"
done | sort -rn

2. O registro de sessões do aplicativo

~/Library/Application Support/Claude/claude-code-sessions/<a>/<b>/local_<id>.json

Um arquivo por sessão, com title, permissionMode, lastActivityAt e, o mais importante, o
cliSessionId, que é o nome do .jsonl do item anterior. É por aqui que você liga o nome
bonito da janela ao arquivo de histórico. Quando uma sessão dá pau, ganha também error,
errorAt e errorCategory.

3. As caixas de entrada vivas

~/.claude/sessions/<pid>.json

Um arquivo por processo de sessão realmente rodando, com o sessionId, a versão e o caminho do
socket. Se a sessão não tem arquivo aqui, ela não está de pé e não recebe nada. Esse é o único
indicador confiável de "a janela está viva".

O que a medição mostrou

Varri todas as pastas de projeto da máquina. Vinte e duas sessões já tinham recebido mensagem em
algum momento. A mensagem mais recente em qualquer uma delas era de 12 de agosto às 15:28
UTC. Depois desse minuto, zero, em todo lugar.

Só a minha orquestradora tinha recebido 125 mensagens nas três semanas anteriores. Depois do
corte: dez envios, de duas sessões remetentes diferentes, todos com recibo de sucesso, nenhuma
entrega.

Corte seco, no mesmo minuto, para todo mundo. Isso não é desorganização de agente, é
infraestrutura.

Um efeito colateral que gera o triângulo de aviso

Quando o processo da sessão de destino não está mais rodando, o envio tenta subir um processo
novo. Ele não responde, e cerca de dezesseis minutos depois o registro daquela sessão ganha:

error: "The session stopped responding. Send your message again to resume with a fresh process."
errorCategory: "timeout"

É o triângulo amarelo que aparece ao lado do nome da sessão na barra lateral. Duas sessões que
recebi mensagem com trinta e quatro segundos de intervalo receberam esse erro no mesmo segundo
exato, o que parece um tempo limite fixo varrido de uma vez.

Então o triângulo não é a doença, é sintoma. E a mensagem morre junto com o processo.

A causa raiz

Isso é público. A issue anthropics/claude-code#86014
foi aberta em 12 de agosto, exatamente o dia do corte, e continua aberta. Tem confirmação em
macOS e em Windows, com análise de log mostrando o antes e o depois da atualização do aplicativo
de desktop. Voltar para a versão anterior do aplicativo não resolve.

O mecanismo, documentado num comentário da thread com despejo de memória, é este:

1. A ponte do aplicativo de desktop envia a mensagem **sem declarar a classe de permissão do

remetente**.

1. A sessão que recebe aplica o portão de consentimento de mensagens entre sessões.
2. Quando a sessão que recebe roda em bypassPermissions e a chave crossSessionInbound não

está definida em lugar nenhum, a regra automática manda segurar a mensagem esperando a sua
aprovação.

1. O aplicativo de desktop não tem tela para essa aprovação.
2. Passados cerca de cinco minutos, o dialogExpiry derruba a mensagem.
3. E quem enviou continua com o recibo de sucesso.

Repare por que isso pega uma esteira inteira de uma vez: se todas as suas sessões rodam em
bypassPermissions, todas elas caem na mesma regra, e nenhuma consegue receber nada.

O conserto

Uma linha em ~/.claude/settings.json:

{
  "crossSessionInbound": "accept"
}

Faça backup do arquivo antes. Com um valor explícito, a decisão automática deixa de valer e cada
mensagem é entregue direto.

Dois detalhes que importam:

Não precisa reiniciar sessão nenhuma. A chave é consultada no momento em que a mensagem
chega, não quando a janela sobe. Eu inicialmente achei que só valia para janela nova, porque a
primeira resposta de volta demorou, mas ela chegou. Janelas abertas antes da mudança passam a
receber na mesma hora.

Sessão com processo morto continua morta. Se a janela está com o triângulo, ela precisa ser
aberta por você. A configuração conserta a entrega, não ressuscita processo.

Ressalva de segurança. accept significa que qualquer sessão sua pode injetar texto em
qualquer outra sem confirmação. São só as suas próprias sessões na sua própria máquina, mas é
bom saber o que você está ligando. Se preferir controle, existe hold, que segura e mostra, e
refuse, que descarta.

Como provar que voltou

Não confie na tela. Com as duas janelas de pé, mande uma mensagem pedindo duas coisas
verificáveis: gravar um arquivo em /tmp com data e hora, e responder para a origem. Depois
confira no disco.

# a mensagem entrou no histórico do destinatário?
grep -c "cross-session-message" ~/.claude/projects/<pasta>/<cliSessionId-do-destino>.jsonl

# ele agiu?
cat /tmp/teste_canal.txt

No meu caso a entrega foi instantânea, o destinatário criou o arquivo cerca de um minuto e meio
depois, e a resposta voltou para a origem. Uma resposta que volta como Message queued apenas
espera o turno em andamento terminar e depois entra, o que antes morria em silêncio.

O hábito que eu recomendo manter mesmo depois de consertado

O arquivo é o repasse, a mensagem é só o aviso.

Escreva a tarefa num arquivo do projeto e use a mensagem apenas para avisar que ela existe. Se o
canal cair de novo, e ele já caiu uma vez, você abre a janela e diz "leia sua tarefa em tal
caminho e execute". Não se perde nada.

Eu já tinha essa regra e mesmo assim me acostumei a mandar o trabalho dentro da mensagem. Quando
o canal caiu, três semanas de coordenação viraram vinte e cinco dias de tarefas que ninguém
recebeu, e eu só percebi porque um resultado esperado não apareceu.

Resumo para quem só quer o conserto

1. Sintoma: send_message responde sucesso e nada chega.
2. Quebrou em 12/08/2026, com a leva de atualização do aplicativo de desktop.
3. Causa: mensagem sem classe de permissão, portão de consentimento segura, aplicativo não

mostra a aprovação, expira em cinco minutos e some.

1. Conserto: "crossSessionInbound": "accept" em ~/.claude/settings.json.
2. Não confie no status verde nem na última atividade, eles mentem. Confira o .jsonl.
3. Janela com triângulo precisa ser aberta na mão.

Issue de referência: https://github.com/anthropics/claude-code/issues/86014
Documentação oficial: https://code.claude.com/docs/en/cross-session-messaging

Recovered here on 2026-08-19 without any change on our side — and a correction to my own exclusion list.

Environment (unchanged from my earlier comments): Claude Code desktop app on Windows 11 (10.0.26200), MSIX 1.30096.5.0, bundled CLI 2.1.220, ~15 concurrent sessions in one workspace.

What happened: delivery failed on every attempt from 16 to 18 August. At roughly 07:00 local on 19 August it started working again, in both directions, and has been reliable since — including Markdown, umlauts and long messages. We changed nothing. No update, no restart, no settings edit, no session recreation. It simply worked again.

Why that matters for @diegomaringa-pixel's root-cause analysis above: I cannot reproduce the precondition. On this machine crossSessionInbound has never been set — and neither bypassPermissions nor any defaultMode appears in ~/.claude/settings.json at all. Under the mechanism described (receiver in bypassPermissions + key unset → auto-hold → dialogExpiry drops it), our sessions should not have been affected in the first place, and the channel certainly should not have recovered on its own while the key is still absent today.

So either there are two distinct failure modes here, or the desktop-app bridge changed behaviour server-side. I can't tell which. I'm reporting the recovery as an observation, not as a fix — if anyone else on Windows saw it come back on 19 August, that would be worth knowing, because a spontaneous recovery points somewhere different from a local config gate.

The correction I owe: in my 18 August comment I listed "no crossSessionInbound, no dialogExpiry, no permissions.deny, no managed-settings file" under things I had excluded as causes. That reasoning was wrong, and @diegomaringa-pixel's analysis is what makes it visible. I checked that no restrictive setting was present and concluded configuration was not involved. But a key that is absent and defaults to "hold" is exactly a configuration cause. The absence of a setting is not the absence of a policy — I had verified the wrong thing, and would have missed this even if it had been our cause.

On the detection method — independent convergence worth noting: we arrived at the same instrument from the other side. The only reliable proof of delivery is the marker

<cross-session-message from="local_..." name="..." encoded="1">

in the receiver's ~/.claude/projects/<folder>/<uuid>.jsonl. Two practical notes we paid for:

• The in-session progress spinner cannot distinguish the two failure shapes. Delivered but never processed (marker present, no assistant turn) and never delivered (no marker at all) look identical on screen. We lost several hours to that. Only the file separates them — and only that separation makes hypotheses falsifiable: "my stuck message is blocking the target" died immediately for one session, because nothing had ever been written there, so nothing could be blocking.
• The cheapest check in practice is not reading transcripts at all: ask for one small visible change with the message (a line in a status file) and then look at that file. We used it twice on 19 August; both times it settled the question in seconds.

And a caution about queued: it is not a failure. It means the target is mid-turn and the message runs after. Re-sending on queued is what wedges the target session so that even hand-typed messages hang there. In our case the damage came from the reaction to the error, not from the error.

Still broken on 1.30096.5.0 — so I BUILT a REPLACEMENT.

If you're blocked on this today, I open-sourced the workaround I am using in
production: a file-based message bus for two paired Claude Code sessions. Each
session writes numbered message files to a shared folder and watches for the
other's; the watcher's output is what wakes the session.

It's turned out better than the built-in channel was even when it worked:

✅ Messages actually arrive — no silent parking, no 16-minute timeout
✅ Nothing is ever lost — a second message can't overwrite the first, Esc can't
discard it, and it survives a restart
✅ Zero tokens while idle — the poll runs in the shell, not in a model turn
✅ Knows if your partner is stuck — a watchdog tells silence apart from a stall,
and says at startup whether it's armed, so it can't be silently inert
✅ Measures real context usage from the session's own transcript, so you stop
guessing
✅ Five small scripts and a folder — no MCP server, no daemon. Tested on Windows
and WSL; macOS should work but I haven't run it there — tell me if it breaks

👉 https://github.com/dApp-Architect/claude-cross-session

Drop-in: register and arm at session start, and the two sessions can talk.
Nothing beyond bash and coreutils, except the context meter which needs python3.
It's a workaround, not a fix — the enqueue path is still broken.

Adding another data point — same symptom, different platform (Linux, local interactive sessions, not Windows):

Environment: Claude Code 2.1.247, Linux, multiple interactive CLI sessions on the same machine (not cloud sessions), all confirmed as live peers via ListAgents.

Repro:

1. Session A (life-tree-86) calls SendMessage({to: "life-tree-45", message: "ping"}) → returns success:true with a valid msg_id.
2. Session B (life-tree-45) gets a new turn (user types directly into it) — no <cross-session-message> ever appears in its context.
3. Reversed direction: session B sends to session A, also success:true — session A has several subsequent tool-call rounds (its own SendMessage/ListAgents calls) and still never receives it.
4. Repeated the send multiple times in both directions with the same result each time — consistent silent delivery failure, not a one-off.

Ruled out "receiver was idle" as the cause, since both directions were tested with the receiving session actively taking new turns afterward. This matches the "reports success but message never delivered" behavior described here rather than the composer/socket-bind variants in #86069 / #84945.