Windows: app-server daemon opens a visible console window for every hook and shell command it runs

Summary

On Windows, once the shared app-server daemon is running (codex app-server daemon start), any Codex TUI session in the same CODEX_HOME silently attaches to it. From then on every hook (pre_tool_use, post_tool_use, user_prompt_submit, …) and every shell command of that session is spawned by the daemon instead of by the TUI — and each one opens a visible console window for as long as the child runs. With per-tool-call hooks configured, that is several windows per tool call, i.e. dozens per minute during normal agent work.

The same session without the daemon (embedded app-server inside the TUI) shows no windows at all.

Environment

• Windows 11 Pro 10.0.26200, Windows Terminal 1.24.11911 set as default terminal
• codex-cli 0.154.0 (standalone install, ~/.codex/packages/standalone/current/bin/codex.exe)
• Source referenced below: commit ddea03ad049142943bdbf13e937b1d67e8c1ba0c (2026-09-10)
• Hooks configured in <project>/.codex/hooks.json (PreToolUse/PostToolUse command hooks), shell pwsh

Reproduction

1. codex app-server daemon start
2. Open a Codex TUI in a project that has command hooks (or just run any shell command); make sure the TUI attaches to the daemon (default launch, no -c/--worktree/--oss).
3. Send a prompt that runs a shell command.

Observed: for each hook and for the shell command a console window flashes up (Windows Terminal, "OpenConsole.exe -Embedding"), visible for the lifetime of the child (typically 0.5–2 s; longer for long-running commands). Process chain captured with a monitor:

window "C:\Program Files\PowerShell\7\pwsh.exe"
  <- OpenConsole.exe -Embedding
  <- conhost.exe
  <- pwsh.exe -Command "..."          (the hook / the command)
  <- codex.exe app-server --listen unix://   (the daemon; its parent has exited)

codex app-server daemon stop makes the windows stop immediately; the TUI falls back to its embedded server.

Cause (from the source)

1. The daemon is launched with no console at all:
   codex-rs/app-server-daemon/src/backend/pid_start.rs:207

   command.creation_flags(DETACHED_PROCESS | CREATE_BREAKAWAY_FROM_JOB);
   

2. Hook and command children are console programs spawned with only CREATE_SUSPENDED — no CREATE_NO_WINDOW:
   codex-rs/hooks/src/engine/command_runner.rs:234-241 (JobObject::spawn_contained, fallback creation_flags(0)), and
   codex-rs/utils/pty/src/win/job.rs:126

   command.creation_flags(CREATE_SUSPENDED).kill_on_drop(true);
   

   A console application whose parent has no console gets a fresh one from Windows, and with Windows Terminal as the default terminal that fresh console is a visible window.

Other daemon-side spawns already avoid this correctly, e.g. managed_install.rs:79,106 and update_loop.rs:448 use CREATE_NO_WINDOW. The hook/command path does not.

What did not help

Starting the daemon process with CREATE_NO_WINDOW instead of DETACHED_PROCESS (so it owns a hidden console) keeps the daemon and its long-lived children (MCP servers, codex-code-mode-host.exe) invisible, but the hook/command pwsh children still get visible windows. So inheriting the parent's hidden console is not sufficient; the flag has to be set on the hook/command spawn itself.

Expected

Hooks and shell commands run by the app-server daemon should not create visible console windows — i.e. spawn them with CREATE_NO_WINDOW (as the updater and installer paths already do), or otherwise ensure they attach to a hidden console.

Impact

Any Windows user who starts the shared daemon (needed for codex agents, remote control, or any external client of the control socket) and has command hooks configured gets a window storm proportional to the agent's tool-call rate, and the only remedy is to stop the daemon.

Start with codex-rs/hooks/src/engine/command_runner.rs and codex-rs/utils/pty/src/win/job.rs, then compare their Windows spawn flags with managed_install.rs and update_loop.rs. Verify the daemon-spawned hook and shell-command processes use CREATE_NO_WINDOW and no longer open visible console windows, while the existing daemon behavior remains intact.