Windows fullscreen TUI: child-process console writes leak into and corrupt the screen buffer (sudden onset, toggled by DISABLE_NONESSENTIAL_TRAFFIC)

Summary

On Windows, output written by a spawned child process onto the console the TUI is drawing on - as opposed to piped stdout/stderr that Claude Code captures - is drawn directly into the fullscreen TUI's screen buffer and never repainted over, permanently corrupting the visible UI until a manual full repaint (resize / ctrl+l).

The trigger is reaching the shared/inherited console, by any route - not the literal CONOUT$ device name. Two routes that both leak:

• A process that opens CONOUT$ by name and writes to it.
• A GUI-subsystem app (OutputType=WinExe) that calls AttachConsole(ATTACH_PARENT_PROCESS) and prints via the normal Console/stdout API. When it is spawned such that it does not inherit Claude Code's capture pipe (e.g. as a grandchild under dotnet run, which does not pass std handles to the GUI child), its stdout handle is empty, AttachConsole binds output to the inherited console, and Console.WriteLine draws onto the TUI.

This is not longstanding behavior. It activated mid-session with no client update, and it can be toggled off at runtime by disabling non-essential traffic - which strongly implicates a server-side experiment/config rollout, not a code change in any particular CLI build. The same dotnet run <app>.cs console apps that logged cleanly for months began leaking within the same minutes-long window as the raw CONOUT$ marker - no rebuild, no logging change on the app side.

Environment

• Claude Code: first observed on 2.1.226; also reproduces on 2.1.227
• OS: Windows 11 Pro 10.0.26200
• Terminal: Windows Terminal 1.24.11911.0 (also reproduces in a freshly spawned WT window)
• Shell: pwsh 7
• Renderer: fullscreen ("tui": "fullscreen")

Reproduction

Route A - explicit console write. In a fullscreen-renderer session, have the assistant run this via the Bash/PowerShell tool:

[System.IO.File]::AppendAllText('CONOUT$', "LEAKED-TEXT`r`n")

Route B - realistic case. Have the assistant run a GUI-subsystem .NET app that attaches to the parent console and logs, launched via dotnet run:

// app.cs, with <OutputType>WinExe</OutputType>
AttachConsole(-1); // ATTACH_PARENT_PROCESS
Console.WriteLine("app line " + DateTime.Now);

dotnet run app.cs

Note the app honors stdout redirection when launched directly (its output goes to a file if you Start-Process -RedirectStandardOutput), so it is not hardcoding the console device - it only reaches the console because, under dotnet run, the GUI child receives no capture pipe and AttachConsole routes it there.

Actual: the text appears drawn over the TUI and persists indefinitely; each subsequent line the app prints scribbles another row onto the UI.
Expected: child console writes are either invisible (child spawned without the TUI's console) or reclaimed by the renderer on the next repaint.

Why this is a server-side regression, not a build regression

Three independent results, each ruling out a candidate cause:

1. Not the CLI version. The same binary (2.1.226) ran a console app clean earlier in the day and leaked later the same day - no reinstall, no version change between the two runs. The 2.1.227 auto-update happened after the first leak, not before it.
2. Not local machine state. The session that first triggered the leak ran no commands touching console/terminal state - HKCU\Console\VirtualTerminalLevel is unset, ForceV2 is at its default, default-terminal delegation is unchanged. A brand-new Windows Terminal window reproduces the leak, so it is not tied to one console instance's state.
3. Toggled by non-essential traffic. Launching with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 - which suppresses the statsig/experiment fetch and falls the client back to baseline behavior - makes the leak disappear entirely (both the raw CONOUT$ marker and a real console app stop leaking). Re-enabling it brings the leak back.

Onset was sharp and mid-session (~2026-08-10 23:03 UTC), consistent with the client picking up a new experiment assignment on a periodic flag refresh.

Active experiments on the affected account

Offered so the team can map the responsible gate (codenames are opaque from the client):

cachedExperimentFeatures: tengu_amber_prism, tengu_copper_fox, tengu_coral_beacon,
tengu_flint_harbor, tengu_mcp_subagent_prompt, tengu_plank_river_frost,
tengu_read_dedup_killswitch, tengu_review_workflow_routing,
tengu_ultrareview_awareness, tengu_velvet_hammer_mythos_5

(enabled per cachedExperimentData: amber_prism, copper_fox, coral_beacon; flint_harbor off.)

Caveat on the evidence

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 disables several subsystems at once (flag fetch, telemetry, auto-update). The version and local-state candidates are independently ruled out above, so the surviving cause is server-fetched config - but "the statsig fetch specifically" is the best-fit inference, not a single-variable proof.

Impact

Any spawned tool whose output reaches the shared console (installers, device software, Write-Progress, native spinners, GUI apps with attach-to-parent-console logging, ordinary dotnet run console apps) scribbles over the session UI. Cosmetic only - session state is unaffected - but the TUI is unreadable until a forced repaint.

Workaround

Run with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 (also disables telemetry and auto-update), or force a full repaint (resize / ctrl+l) after a leak.

Suggested fixes

• If a renderer/spawn experiment is responsible, gate it off on Windows until child-process console writes are handled.
• Spawn tool child processes with a detached/hidden console on Windows so their console writes (whether explicit CONOUT$ or via AttachConsole) cannot reach the TUI buffer, or
• have the fullscreen renderer do a full repaint after each tool call so stray cells are reclaimed.