Codex fresh local sessions fail to discover rollout file, blocking remote takeover

[Cheddies1]

Summary

A fresh Codex session started with happier codex appears in the web UI, but Happier never discovers the Codex rollout file. The session remains stuck in local mode and cannot accept remote commands.

Resuming an existing Codex rollout bypasses the failure and allows switching between local and remote control normally.

Environment

• Happier CLI: 0.2.1-preview.1775503793.4227
• Platform: Linux x64
• Packaged runtime: Bun 1.3.11
• Bundled Node compatibility runtime: v24.3.0
• Codex CLI: 0.144.3
• Happier Cloud: https://api.happier.dev

Working control test

Resuming the same Codex session through the extracted CLI works:

HAPPIER_CODEX_SESSIONS_DIR="$HOME/.codex/sessions" \
"$HOME/.happier/tools/js-runtime/current/runtime/bin/node" \
"$HOME/.happier/cli/versions/0.2.1/package-dist/index.mjs" \
codex --resume <codex-session-id>

Using that command, switching from local to remote and back to local works correctly.

Likely fault boundary

The evidence points to the fresh-session fast-start/deferred-session path.

Fresh terminal-started sessions use DeferredApiSessionClient and runStartupCoordinator. Resume mode bypasses that fresh-session path and works with the same runtime, rollout directory and Codex installation.

The standalone rollout discovery function also works, suggesting the failure is in how discovery or the discovered session ID is handled by the full fresh-session launcher.

Additional observation

A failed remote-switch attempt can leave terminal mouse handling enabled or otherwise damage mouse input in the local terminal. Terminal input can be recovered with:

printf '\033[?1000l\033[?1002l\033[?1003l\033[?1006l'
stty sane

This may be a separate terminal cleanup issue and can be split into another report if preferred.

What happened (current behavior)

Actual behaviour

The web UI reports:

Codex rollout file not found yet - waiting for it to appear...
Switched to local mode
Codex rollout file still not found - continuing to wait for it to appear...

Attempting remote takeover reports:

Waiting for Codex session to initialize before switching to remote mode...

Remote commands are not delivered.

The rollout file does exist under:

$HOME/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl

It contains valid session_meta, including:

• a fresh timestamp matching the Codex process start
• the correct working directory
• a valid Codex session ID
• originator: codex-tui

Happier nevertheless continues to report hasOpenCodeSessionId:false.

Expected behaviour

Once Codex creates the rollout file, Happier should discover the session ID, mirror the rollout and allow switching between local and remote control.

Steps to reproduce

1. Start a fresh session:

   happier codex

2. Submit a local prompt such as:

   test
   

3. Wait for Codex to respond.

4. Open the session in the Happier web UI.

5. Attempt to switch the session to remote mode.

6. Send a command from the web UI.

Diagnostics performed

The failure reproduces with all of the following:

Normal packaged CLI

happier codex

Explicit rollout directory

HAPPIER_CODEX_SESSIONS_DIR="$HOME/.codex/sessions" happier codex

Extracted CLI using Happier's bundled Node runtime

HAPPIER_CODEX_SESSIONS_DIR="$HOME/.codex/sessions" \
"$HOME/.happier/tools/js-runtime/current/runtime/bin/node" \
"$HOME/.happier/cli/versions/0.2.1/package-dist/index.mjs" codex

The same symptoms occur in all three cases. This rules out the compiled Bun executable and default sessions-directory resolution.

Calling the packaged discoverCodexRolloutFileOnce() function independently, under the same bundled Node runtime and using the real launch timestamp and working directory, immediately returns the correct rollout file.

There are no relevant errors in the Happier log. The rollout discovery code appears to catch filesystem and parsing errors without logging them.

Severity

blocker

Frequency

always

Happier version

0.2.1-preview.1775503793.4227

Platform

Linux x64

Server version

No response

Deployment type

cloud

What changed recently?

No response

Diagnostics ID

No response

Additional context

No response

[Cheddies1]

Successful mitigation test

The extracted 0.2.1 runtime was patched so shouldFastStartLocal is false for fresh Codex sessions while remaining available for eligible resume sessions. The patched runtime was exposed through a separate happier-patched wrapper, leaving the installed binary untouched.

With that change, a fresh session completed the full control cycle successfully:

1. Start fresh in local mode.
2. Submit the first local prompt so Codex creates the rollout.
3. Switch to remote mode.
4. Submit a remote prompt and receive the Codex response.
5. Switch back to local mode.
6. Continue the same session locally with the existing transcript intact.

This confirms that bypassing fresh-session fast-start restores rollout discovery and bidirectional local/remote switching. It narrows the defect to the fresh fast-start/deferred-session path, but does not by itself identify the failing operation inside that path.