shell_execute flashes a terminal frame per call on Windows-Terminal-default boxes; run_script's belt does not cover the cmd path

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues20 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

John, using ConfRoomROG while a test sweep drove it over the relay (2026-09-01): "little 50ms blips on the screen like a cmd window is opening/closing really quick... i keep wondering if its some of my other bridges."

Cause: shell_execute spawns cmd /Q /S /C "<command>" with CREATE_NO_WINDOW (commands.rs, execute_shell_command). That flag is honored fully by classic conhost, but on boxes where Windows Terminal is the default console host a terminal window can still materialize for a frame per spawn. ab already knows this gap: issue #77's fix gave run_script's powershell path -WindowStyle Hidden as belt-and-braces, with a comment naming exactly this mechanism. The cmd path (shell_execute, and run_script with interpreter=cmd) has no equivalent, cmd.exe has no WindowStyle flag.

A driver that fires shell_execute in a loop (our ralph sweep: hundreds per run) turns this into a visible blip storm on the box's console while a human is using it, and they cannot tell which of their bridges is doing it.

Suggested fix: on Windows, route the cmd path through classic conhost explicitly, e.g. exe = "conhost.exe", args = ["--headless", "cmd", "/Q", "/S", "/C", command], keeping CREATE_NO_WINDOW. conhost --headless never delegates to Windows Terminal, so the frame cannot appear. Same treatment for run_script interpreter=cmd. The powershell path is already covered by #77.

We have also reduced our own call volume (batched loops into single run_script calls), but any AI driving shell_execute in a loop reproduces this on a WT-default box, so it is worth fixing at the spawn site.

1 Reply

John Lauer · 2mo ago

Measured on ConfRoomROG itself before touching any code, and the data says: no change to shell_execute, and the suggested conhost fix would actively break it. Three measurements:

1. The CNW premise does not reproduce — even under a storm on the reporting box. I ran your own watcher design (EnumWindows poll at 25ms for visible ConsoleWindowClass / CASCADIA_HOSTING_WINDOW_CLASS / PseudoConsoleWindow, 30s window) on ConfRoomROG while firing 95 shell_execute calls through the relay, each spawning cmd /Q /S /C plus a console-subsystem grandchild (ping). Result: HITS=0. Zero visible console-class windows, storm-long, on the same Windows-Terminal-default box where the blips were seen. This agrees with your #113 watcher data: every flash it caught was a spawn relying on the interpreter's own hide flag (wShowWindow), never a CREATE_NO_WINDOW spawn. CNW prevents the console session from delegating visibly; wShowWindow is the broken path.

2. conhost --headless breaks the stdio contract. Tested both wrapper shapes with piped stdio + CREATE_NO_WINDOW:

conhost --headless cmd /Q /S /C "echo hi & exit /b 3" → stdout comes back ConPTY-cooked: VT escape sequences (\x1b[?9001h\x1b[?1004h...), screen-clear and title sequences mixed into the output, lines re-wrapped at console width — and the exit code is lost (rc 0, not 3), stderr merged away.
conhost cmd ... (no --headless) → same ConPTY cooking. A caller doing shell_execute and parsing stdout/exitCode would get garbage. It works for your scheduled-task fix precisely because Task Scheduler has no stdio contract to break — but shell_execute does.

3. DETACHED_PROCESS (the other no-console idea) loses grandchild output. A detached cmd's console-subsystem child allocates its own console and its stdout no longer reaches the pipe (measured: probe output vanished entirely).

So the blip storm during your ralph sweep attributes to #113's two real causes: the hand-registered \AdomBridgeKeepAlive task (every minute at :02 — not ab's; see my #113 reply) and any launch_process call without window:"hidden". shell_execute's CNW path was never implicated by either watcher.

Your own watcher is now in the repo as scripts/diag-console-blips.ps1 — if you ever see blips correlated with a shell_execute loop again, run it during the loop and reopen this with the HITS lines; that would be new evidence worth chasing.

John Lauer closed this · 2mo ago