[Bug] Background subprocesses flash console windows on native Windows

[wnsgh3810]

Affected area

Coding agent and CLI (native Windows subprocess lifecycle)

What happened?

Starting Prime Agent on native Windows causes multiple console windows to appear and disappear rapidly. After startup, a console window titled prime-agent can remain open for the lifetime of the session.

The TUI itself still runs correctly in its host terminal. The extra windows come from background Node and command-line subprocesses that do not set Node's windowsHide child-process option.

The persistent process is the daemon catalog child launched as prime-agent --version with PRIME_AGENT_INTERNAL_DAEMON_CATALOG=1. A process snapshot showed this tree:

prime-agent TUI
`-- prime-agent --mode daemon
    |-- prime-agent --version       (daemon catalog; long-lived)
    `-- prime-agent --mode daemon   (session worker)

The catalog child also acquired a conhost.exe. Short-lived startup checks and other daemon/worker launches account for the transient windows.

Steps to reproduce

1. Install Prime Agent 0.7.2 on native Windows.
2. Launch it from a GUI-hosted ConPTY terminal. I used Orca with:
   prime-agent --offline --provider openai-codex --model gpt-5.6-sol
3. Observe several console windows flash during startup.
4. After the TUI becomes idle, observe a separate console window titled prime-agent remaining open.

The issue happens before any model request and is independent of the selected provider.

Expected behavior

Prime Agent should remain connected to the terminal that launched it, while all background daemon, worker, catalog, and command-check subprocesses run without creating separate Windows console windows.

Input, output, Ctrl+C handling, IPC, and exit-code propagation should remain unchanged.

Prime Agent version

0.7.2; the relevant call sites are also present on current main at 06e4a19dc902382dbb90b67fbe4ed53c3f7b99b2.

Environment

• Native Windows 11 Home, build 26200
• Node.js 24.15.0
• npm 11.12.1
• Git for Windows / Git Bash installed
• Orca ConPTY terminal

Additional context

Windows-reachable background call sites currently omit windowsHide, including:

• packages/coding-agent/src/modes/daemon/daemon-catalog-process.ts (spawnCatalog)
• packages/coding-agent/src/cli/daemon-launch.ts
• packages/coding-agent/src/cli/daemon-command.ts
• packages/coding-agent/src/cli/daemon-update-restart.ts
• packages/coding-agent/src/cli/owned-session-worker.ts
• packages/coding-agent/src/modes/daemon/daemon-mode.ts
• packages/coding-agent/src/modes/daemon/daemon-supervisor.ts
• Windows command checks in packages/coding-agent/src/utils/shell.ts and tools-manager.ts

As a local diagnostic, adding windowsHide: true only to detached daemon/worker launches and the catalog launch removed the persistent window but did not eliminate every transient flash. Enforcing windowsHide: true across Prime Agent's spawn, spawnSync, execFile, execFileSync, and fork calls eliminated both the transient windows and the persistent catalog window. The global interception was useful for diagnosis, but I would not propose it as the upstream implementation.

A focused fix could consistently add windowsHide: true to Windows-reachable background subprocess options, potentially through a small shared helper so future call sites do not regress. Regression tests can mock the child-process launch functions and assert that daemon, worker, catalog, and command-check launches receive windowsHide: true. This does not change the daemon protocol or IPC shapes.

I can prepare the focused source change and tests if a maintainer would like a pull request.

[1xadz]

Still reproducible on prime-agent@0.7.2 (Windows 11, npm install). I traced where the flood actually comes from, since the 0.7.2 change only added windowsHide: true to executeWithConfiguredShell in resolve-config-value — a spawn site that's barely ever hit.

The main offender is runProcessQuery in core/session-lease.ts:

function runProcessQuery(command, args) {
    return execFileSync(command, args, {
        encoding: "utf8",
        stdio: ["ignore", "pipe", "ignore"],   // no windowsHide
    });
}

On Windows, getProcessStartId() shells out to a fresh powershell.exe per call (getWindowsProcessStartId), and it's called from polling loops in cli/daemon-ps.js, e.g.:

while (getProcessStartId(listener.pid) === processStartId && Date.now() < deadline) { ... }

Each iteration spawns a new PowerShell. The daemon runs without an attached console, so every spawn allocates a visible console window — that's the storm of windows flashing open/closed. Linux/macOS are unaffected because getProcessStartId reads /proc/<pid>/stat (or ps) there, matching reports that this is Windows-only.

I patched my installed 0.7.2 by adding windowsHide: true to runProcessQuery (in dist/core/session-lease.js and its bundled copy) and the windows are gone, so that one line removes the symptom. Two follow-ups worth doing:

1. Cache the start-id per PID — it's immutable for a live process, and the current loops pay ~100–200 ms of PowerShell startup per poll iteration.
2. Sweep the remaining spawn sites that also omit windowsHide: core/exec.js, core/autonomous.js, core/package-manager.js (2×), core/tools/bash.js, core/kernel/index.js / bootstrap.js / fork-server.js, and the clipboard reader in utils/clipboard-image.js (the kernel ones were already listed in Windows: detached child processes open visible console windows #668 before it was closed).

[Noobear]

Confirmed this is still present in Prime Agent 0.8.0 on native Windows (build 26200) with Node.js 24.18.0.

I inspected the installed 0.8.0 bundle and the daemon, session-worker, catalog, command-check, and IPython kernel launch paths still reach child_process calls without consistently setting windowsHide: true. This matches the original report in #668 and the call sites listed above.

As an update-resistant local workaround, I now launch Prime Agent through a user-level wrapper that injects a Node preload hook. The hook wraps spawn, spawnSync, exec, execSync, execFile, execFileSync, and fork, forces windowsHide: true, and calls syncBuiltinESMExports() so named ESM imports also receive the wrapped functions. The generated package files remain untouched, so Prime Agent updates do not remove the workaround.

That global hook is useful as a diagnostic/workaround, but it should not be the upstream implementation. Please consider accepting a focused patch that:

1. centralizes Windows-safe child-process options in a typed shared helper;
2. covers daemon, supervisor, worker, catalog, session-lease/PowerShell polling, package/bootstrap, and kernel launch paths; and
3. adds Windows-oriented regression tests asserting windowsHide: true at those boundaries.

This is a significant usability issue on native Windows because polling or recovery loops can turn a single missing option into a burst of visible console windows. I would be happy to validate a candidate fix on the environment above.

[chimin-roh]

Confirming on Windows 11. Still present in v0.8.0.

windowsHide appears exactly once in the 0.8.0 source (resolve-config-value.ts:40). The spawns that produce the visible flashing do not set it:

• daemon launch (cli/daemon-launch.ts:371)
• owned session worker (cli/owned-session-worker.ts:346)
• kernel bootstrap run()

Symptom matches what is described here: the terminal flashes several times per turn, and one kernel console window stays visible. Setting windowsHide: true on those spawns resolves it locally.

[telemetrya2018-dotcom]

Still reproducible on prime-agent@0.9.1 on native Windows, and the persistent blank tab now has a precise kernel-specific reproducer.

Environment

• Windows 11 on native Windows Terminal 1.24.11911.0
• Prime Agent 0.9.1 from npm
• Node.js 24.15.0
• Kernel Python 3.11.15

Reproduction

1. Resume an existing session with prime-agent --resume <session-id> in Windows Terminal.
2. The intended Prime Agent TUI tab opens.
3. When the persistent Python kernel starts, a second blank Windows Terminal tab appears with the application title D:\PrimeAgent\python\kernel-venv\Scripts\python.exe.
4. Let the assistant turn finish and return to needs_input / idle.
5. The blank Python tab remains visible.

In one observed run the process timestamps matched exactly:

10:07:28  node.exe worker PID 44464
10:07:45  python.exe PID 13820: ...\python.exe -m rlm.repl
10:07:45  extra OpenConsole.exe PID 11620

The Prime session was idle (isStreaming=false, isRunningTools=false, unfinishedActionCount=0) while both the rlm.repl process and its blank console tab remained alive. Keeping the kernel process alive may be intentional; keeping its console visible is the bug.

Current 0.9.1 source path

The source map for the shipped package points to packages/coding-agent/src/core/kernel/repl-manager.ts. Its REPL launch is:

const child = spawn(python, ["-m", "rlm.repl"], {
  cwd: this.options.cwd,
  env: {
    ...process.env,
    ...this.options.env,
    PRIME_AGENT_KERNEL_OWNER_PID: String(process.pid),
  },
  stdio: ["pipe", "pipe", "pipe"],
});

There is still no windowsHide: true on this spawn. The installed generated file has the same omission at dist/core/kernel/repl-manager.js.

Expected behavior

Starting or resuming a chat must not create any extra visible Windows Terminal tabs. The long-lived rlm.repl child should remain fully piped and hidden, and ending a turn should leave only the original Prime Agent tab.

Suggested focused fix

Add windowsHide: process.platform === "win32" (or the equivalent shared Windows-safe spawn helper) to the rlm.repl spawn and retain the broader Windows subprocess sweep proposed above. A regression test should mock the kernel spawn and assert that the Windows path sets windowsHide while preserving stdio, environment, shutdown, and exit-code handling.

This is the same bug family as closed issue #668, but it remains reproducible in the current 0.9.1 release and now has a direct rlm.repl call site.

[telemetrya2018-dotcom]

Urgent follow-up: this is release-blocking on Windows

This is not a cosmetic annoyance. On native Windows, Prime Agent 0.9.1 becomes effectively unusable for real work.

Every RLM/subagent kernel launch (python.exe -m rlm.repl) can create a separate blank console/Windows Terminal window. That window takes foreground focus and then closes. During a normal agent run this happens repeatedly—potentially dozens of times. If the user is typing in Codex, an editor, or another application, their input is interrupted or lands in the popup. A blank console can also remain open after the run.

Reproduction

1. Start Prime Agent 0.9.1 on native Windows from Windows Terminal.
2. Run a task that repeatedly invokes RLM/subagents.
3. Observe a visible OpenConsole.exe/Terminal window for each background kernel start and exit.

This should have been caught by a basic native-Windows multi-kernel smoke test. Please treat the missing coverage as a release-gate gap and ship an urgent hotfix:

• pass windowsHide: true on every Windows child_process launch path for background Python/kernel processes, including the distributed bundle;
• ensure background subprocesses never activate a visible terminal or steal focus;
• add a Windows regression test that launches multiple kernels and verifies no top-level console window is created;
• verify shutdown leaves no orphan OpenConsole.exe window behind.

We confirmed locally that applying windowsHide at the rlm.repl spawn sites stops the window storm while the kernels continue to run and complete tool calls normally. Please prioritize this and publish a patched release—the current behavior prevents users from typing or working while Prime Agent is active.