Windows native WezTerm: `/ask codex` gets stuck at "Codex processing..." because async PowerShell wrapper never starts

[oyasumi-mu]

Bug Description

On native Windows with WezTerm, when Claude uses /ask codex "...", Claude shows:

• [CCB_ASYNC_SUBMITTED provider=codex]
• Codex processing...

but the Codex pane shows no reaction at all.

This is not a pane-routing issue. The target Codex session is active and bound to the correct project/pane, but the async background wrapper never actually starts the foreground ask codex execution.

Environment

• CCB version: v5.2.6
• Terminal: WezTerm
• OS: Windows 10 native
• Claude Code: v2.1.90
• Codex CLI: v0.118.0
• WezTerm: 20240203-110809-5046fc22

Reproduction

1. Open WezTerm on native Windows
2. Start CCB:

   ccb codex gemini claude

3. In Claude pane, run:

   /ask codex "test"
   

4. Observe:
   • Claude reports async submission successfully
   • Codex pane remains unchanged
   • No visible input is submitted to Codex

Expected

The message should be injected into the active Codex pane and submitted normally.

Actual

Claude reports Codex processing..., but Codex receives nothing.

What I Verified

Session routing is correct

The project .ccb/.codex-session was active and pointed at the correct WezTerm pane, for example:

• terminal: "wezterm"
• active: true
• pane_id: "2"
• pane_title_marker: "CCB-Codex-..."

The bound Codex session log path also matched the correct project.

Codex log shows no injected ask request

The Codex session log did not contain the expected injected request content (CCB_REQ_ID, test prompt, etc.), which suggests the request never reached the Codex pane.

Async task wrapper never really starts

In %TEMP%\ccb-tasks, the generated files looked like this:

• ask-codex-<task>.status
• ask-codex-<task>.ps1
• ask-codex-<task>.msg
• ask-codex-<task>.log

But the .status file only contained:

submitted ...
spawned pid=...

It never wrote the next line that the PowerShell wrapper should immediately append:

running pid=...

Also, the .log file stayed empty.

That strongly suggests the detached PowerShell wrapper itself failed before it ever executed:

python "<install>/bin/ask" codex --foreground ...

Suspected Root Cause

On Windows, bin/ask async mode currently generates a detached PowerShell script and launches it in the background.

That detached PowerShell wrapper appears to fail to start cleanly under native Windows + WezTerm + Claude Code, so the request never reaches the foreground ask codex path and never gets injected into the Codex pane.

Suggested Fix

In bin/ask, for Windows async mode, avoid the extra detached PowerShell wrapper and instead spawn the foreground path directly with the current Python interpreter, e.g. conceptually:

subprocess.Popen(
    [sys.executable, ask_cmd, provider, "--foreground", "--timeout", str(timeout)],
    stdin=msg_handle,
    stdout=log_handle,
    stderr=subprocess.STDOUT,
    env=child_env,
    creationflags=DETACHED_PROCESS | CREATE_NO_WINDOW | CREATE_NEW_PROCESS_GROUP,
)

This avoids the failing PowerShell layer and still preserves the async behavior.

Notes

This issue is different from pane title collisions / wrong-pane routing.
The provider pane and session binding were correct; the background launcher itself seems to be the failure point.

[bfly123]

I reconstruct ccb Completely. And it will come soon