[Bug]: Codex Coding Agent often waits ~120s in Ekko Studio v0.7.21 while native Codex completes in ~5s

Ekko Studio Version

v0.7.21

Agent Runtime and Version (if applicable)

Codex CLI v0.154.0

Bug Description

Codex Coding Agent requests in Ekko Studio are consistently much slower than native Codex CLI.

A minimal prompt such as:

只回复 OK

usually completes in about 5 seconds when sent directly through native Codex CLI, but the same request through Ekko Studio frequently takes around 120 seconds.

During the delay, Ekko logs repeatedly show the session remaining in working=true. In some runs, codex exec exited only appears after the task is manually aborted; in other runs, the response appears almost exactly around the 120-second mark.

I also performed an isolation test:

• Ekko scoped config.toml is byte-for-byte identical to my native ~/.codex/config.toml
• node_repl, basic-memory, and blender MCP servers were temporarily disabled
• The ~120 second delay still reproduced

This suggests the issue is likely in the Codex Coding Agent run/session lifecycle or completion-event handling rather than those MCP servers or the Codex configuration itself.

Static inspection of the bundled server code also found relevant 120-second waits in runAndWait() and streamOutput(). I can provide the detailed logs and investigation results below.

Steps to Reproduce

1. Launch Ekko Studio v0.7.21 on macOS.

2. Start a Codex Coding Agent session using Codex CLI v0.154.0.

3. Use the same workspace, model, and Codex configuration that work normally in the native Codex CLI.

4. Send the minimal prompt:

   只回复 OK

5. Measure the response time.

Native Codex usually completes the same type of request in about 5 seconds, while Ekko frequently waits around 120 seconds.

I also performed an isolation test by temporarily disabling these MCP servers only in Ekko's scoped Codex configuration:

• node_repl
• basic-memory
• blender

The ~120 second delay still reproduced.

No native Codex configuration, authentication files, plugin caches, marketplaces, model caches, or Ekko application files were modified.

Expected Behavior

A simple Codex request should complete within a few seconds, close to the native Codex CLI behavior.

When Codex finishes, Ekko should immediately:

• receive the completion event;
• resolve the corresponding run waiter;
• mark the session as no longer working;
• display the final response in the UI.

The Coding Agent should not remain in working=true until an approximately 120-second timeout.

Actual Behavior

Native Codex CLI usually replies in approximately 5 seconds.

Through Ekko Studio, the same minimal request frequently takes 1–2 minutes, and multiple runs have completed almost exactly around the 120-second mark.

During the delay, the Ekko session remains working=true.

In some runs, codex exec exited only appears after manually stopping the task.

In another isolation test, I did not abort the request. It remained running for approximately 120 seconds and then finally returned a response.

Disabling node_repl, basic-memory, and blender did not change the behavior.

Logs / Error Messages

[coding-agent-run] print runner started
[coding-agent-run] recorded Codex native session id
[chat-run-socket] resumed session ... (working: true)
[chat-run-socket] resumed session ... (working: true)
...
[coding-agent-run] codex exec exited
[chat-run-socket] external run completed In problematic runs, `working=true` persists for a long time before the completion/exit event.

Repeated session resume events were observed, and in some cases the same run produced multiple `codex exec exited` log entries.

Environment

macOS

Node Version

No response

Additional Context

Ekko's scoped Codex configuration was compared against the native Codex configuration.

The scoped file:

~/.hermes-web-ui/coding-agent/model/default/global/codex/runs/<run-id>/config.toml

and:

~/.codex/config.toml

were byte-for-byte identical. File size, SHA-256, and cmp all matched.

Static inspection of:

Contents/Resources/webui/dist/server/index.js

found several relevant 120-second waits.

chat-run-socket.runAndWait() waits for:

• run.completed
• run.failed

and contains a timeout/abort path using a 120000 ms deadline.

A related Codex output path also contains:

streamOutput(run_id, { timeoutMs: 12e4 })

where 12e4 = 120000 ms.

I cannot confirm the exact defect, but the observed behavior appears consistent with a completion/state propagation issue:

Codex completes or produces final output → Ekko does not immediately resolve the corresponding run waiter → sessionMap.isWorking remains true → the outer run waits until the 120000 ms deadline → timeout / abort / cleanup releases the session or final result.

Potential areas worth checking:

• Codex completion event → runWaiter resolution
• printCompleted vs run.completed
• session_id / run_id mapping
• streamOutput() EOF / terminal event handling
• native Codex session resume handling
• markExternalRunCompleted()
• clearing isWorking

This is only a suspected root cause based on logs and static inspection, not a confirmed code-level diagnosis.