Repository navigation
bug: native Windows Claude reports posted but the live TUI receives no message #157
Description
RC1 live validation blocker from #150
Native Windows session-peer 1.0.0rc1 reports ok: true / posted for a live named Claude session, but the user confirms that the target TUI shows no incoming message or approval/startup prompt. No actual ACK was observed. This is distinct from Codex's #153/#156 failures.
Environment: Windows, Python 3.10.0, pip-user RC1, native Claude Code 2.1.278. list --agent claude --json reports the user-selected interactive session as idle, alive and reachable. A local Windows validator independently reproduced the missing ACK.
Bounded diagnosis
- Registry PID matches the running native
claude.exeprocess. GetNamedPipeServerProcessIdon the exact registered pipe matches the same PID, ruling out a wrong/stale pipe owner for this probe.- Exactly one auth-key file exists for that PID, created with the session. Only metadata was inspected; no credential values were logged or attached.
- One independent authentication-only diagnostic connected to that pipe and wrote the same auth JSON shape used by RC1. It sent no user message.
PeekNamedPipeimmediately returned Win32 error 109 (ERROR_BROKEN_PIPE); no protocol response was read. - RC1
_post_to_pipewrites the auth line and user line to a write-only buffered handle, flushes and sleeps. It does not inspect authentication acceptance/server closure before reportingposted.
The auth-only observation suggests a handshake/connection rejection, but the exact reason is not yet established. Do not claim that missing UI reception is caused by a specific token field or change the auth protocol without evidence. posted has always been a write-level status, not consumption; nevertheless this is a supported native path that fails the required live gate.
Reproduction
- Start a native Windows Claude interactive session with its normal messaging registration.
- Discover and select that exact session with RC1.
- Send one unique harmless marker asking only for a visible ACK; observe CLI
posted. - Inspect the actual receiving TUI: no message appears; no ACK is generated.
Previously submitted messages were not retried because their application outcome was unknown. Do not work around this by disabling auth, changing inbound permissions, or copying credentials.
Acceptance
Determine and fix the supported native Windows authentication/framing contract; return a clear failure when rejection is observable; preserve the distinction between write acceptance and agent consumption. Add auth rejection, missing/stale key, pipe disconnect and framing regression tests. Validate one fresh authorized marker in a live Windows Claude TUI and observe its actual ACK before closing the RC2 gate.
Activity
abruption commentedon Sep 22, 2026
First-user-turn comparison: the user clarified that the original native Claude TUI had never received a manual user prompt. They have now entered a READY request and confirmed its response completed. Rediscovery still resolves the same interactive claude-main PID and pipe. One NEW uniquely marked message (RC1-WIN-AFTER-READY-150-9d824b6e) was sent once with --no-reply-to, asking only for an on-screen ACK and no tools. RC1 returned exit 0 / ok:true for the write. Actual UI reception/ACK is awaiting user observation; do not mark this post-initialization comparison passed or failed yet. None of the previous unknown messages was retried.
abruption commentedon Sep 22, 2026
Post-initialization comparison result: the user confirms that no response appeared for RC1-WIN-AFTER-READY-150-9d824b6e after the manual READY turn had completed. Therefore the actual ACK gate still FAILS after the first user turn; lack of an initial user prompt alone does not explain the observed failure. The CLI write result remained ok:true. Do not infer which internal stage dropped the message from the absent response alone. The user suggested WSL-only operation explicitly as a hypothesis, not a verified workaround or support boundary. No equivalent WSL-hosted Claude live ACK test has established that claim; #156 concerns WSL access to native Windows Codex and must not be conflated with this Claude issue. No further message was sent or retried. Keep this issue open in RC2 pending native pipe authentication/framing diagnosis and a successful live ACK.
abruption commentedon Sep 22, 2026
Native shell comparison: rediscovery resolves claude-powershell (PID 11284, kind=bg) and claude-cmd (PID 28740, kind=interactive), both Claude 2.1.278 and alive/reachable. Important confounder: the old claude-main (PID 14396, interactive) still exists separately; do not interpret the named PowerShell target as the renamed original interactive process without further confirmation. Sent exactly one fresh no-tools/on-screen-ACK marker to each explicitly named target: RC1-PS-150-72d39a41 and RC1-CMD-150-c519bf83. Both RC1 commands returned exit 0 / ok:true. Actual ACKs are awaiting user observation; neither is counted as passed. WSL-hosted Claude comparison has been proposed but has not yet been run.
abruption commentedon Sep 22, 2026
User-observed result of the native shell comparison: neither claude-powershell (RC1-PS-150-72d39a41) nor claude-cmd (RC1-CMD-150-c519bf83) showed any reaction. Both sender commands had returned exit 0 / ok:true, but neither actual ACK gate passed. Keep the interpretation narrow: the PowerShell-named endpoint is registered kind=bg and the original interactive claude-main remains separate, so this is not a controlled identical-session shell A/B comparison. Native CMD interactive reception also failed in this run. WSL-hosted Claude has not yet been tested; WSL-only support remains an unverified hypothesis. No additional messages were sent or retried. RC2 blocker remains open.
abruption commentedon Sep 22, 2026
User-requested 0.9.1 comparison: installed exactly session-peer==0.9.1 into a new isolated native Windows Python 3.10 venv, leaving the default pip-user 1.0.0rc1 installation unchanged. Verified old CLI version and clean isolated pip check, and independently verified default CLI remains 1.0.0rc1. Using the 0.9.1 CLI, rediscovered the same claude-powershell PID 11284 (kind=bg) and claude-cmd PID 28740 (interactive), Claude 2.1.278. Sent ONE fresh marker per target with no reply route/tools: V091-PS-5c3fa281 and V091-CMD-e68b0472. Both 0.9.1 commands returned exit 0 / ok:true. Actual on-screen ACK results await user confirmation. This does not yet establish or rule out an RC1 regression. No previous unknown message was replayed and no session/auth settings were changed.
abruption commentedon Sep 22, 2026
Windows Claude auth diagnosis — 2026-09-22
Confirmed observations
type=auththen copies the registry key JSON fields wholesale. Actual key field names arepeerToken,procStartFt,pidDomain; notokenfield is emitted.type=authandtoken. Native Windows rejects an invalid first auth line. Source: https://code.claude.com/docs/en/cross-session-messaging#the-sessions-inbox-socketEarlier test evidence
Canonical original Claude project session: 1556fe2c-ec97-4024-8ccf-e8b0371d76ef, 2026-09-08 UTC.
Release implications and remaining work
Affected stable 0.9.1 users cannot rely on RC2 alone. A narrowly scoped 0.9.2 hotfix is a recommended release option, with the same fix ported to the RC line. The user specifically identified update-induced stable breakage as a hotfix concern; update causality remains unproven. No release was authorized/executed by this diagnosis.
Implementation still required: validate/translate the on-disk key schema into the supported auth envelope; handle observable pipe rejection without implying consumption; cover malformed/stale/missing keys and authentication framing; preserve inbound controls. A live corrected native-Windows message and actual ACK must pass before claiming the fix works. Do not change permission settings, bypass authentication, or replay unknown old messages.
Only diagnostic scripts and this evidence were authored. Repository source and both installed CLI versions remain unmodified.
abruption commentedon Sep 22, 2026
Causal live test confirmed by the user: using isolated 0.9.1 with ONLY the in-memory auth-envelope builder changed to {type:auth, token:}, the CMD receiver displayed the complete new TOKEN-CMD-157-84e27ac9 message and generated an assistant response discussing that exact request. Discovery, CLI, user framing and pipe write/flush/close code were unchanged. Thus the token-field mapping fixes the observed transport failure. The model declined to output the requested exact ACK until direct user confirmation; distinguish this application-level refusal from delivery failure. User has authorized hotfix preparation conditional on validation. Preparing minimal 0.9.2 stable fix and RC forward-port, with exact ACK still awaiting direct user confirmation. No inbound setting, auth bypass or release publication is involved.
abruption commentedon Sep 22, 2026
Fresh built 0.9.2 wheel installed into a separate native Windows venv (default RC1 and isolated 0.9.1 preserved). One fresh message to the rediscovered interactive claude-cmd produced visible content and an actual Claude response, independently pasted by the user: marker WIN-CLAUDE-092-6b9e40a2. Claude requested direct user confirmation for this second ACK; no permission/inbound settings were changed. Thus the auth-envelope fix is confirmed on the packaged candidate, while exact ACK remains pending receiver-side user confirmation. This is not a transport failure or evidence that native Windows requires WSL. Prior 0.9.1 source already contains the malformed auth envelope; a new Claude update regression is not established. PR will preserve posted/consumption distinction.
abruption commentedon Sep 22, 2026
Final native Windows packaged-candidate gate passed: after direct user confirmation in the receiving Claude TUI, the user confirmed the exact ACK WIN-CLAUDE-092-6b9e40a2 succeeded. 0.9.2 candidate wheel actual delivery and ACK are now verified. No permission settings changed. Preparing stable hotfix and RC forward-fix PRs; do not close until CI/release acceptance review.
abruption commentedon Sep 24, 2026
RC4 five-host rerun rc4-rerun-02 confirms native Windows Claude exact TUI ACKs at T0 and T240. The original T120 TUI closed and its ACK remains unconfirmed (campaign total 20/21); a distinct one-shot check of the same native path subsequently returned an exact ACK. The user explicitly accepted this operational exception in #164. This closes the RC1 pipe-delivery regression, not the historical evidence gap.