Summary

When using the codex provider plugin (Codex CLI app-server via stdio), the session lane lock is never released after a run completes. This means the first message in a session gets a response, but every subsequent message queues indefinitely behind the stale lock.

Environment

• OpenClaw: 2026.4.14 (323493f)
• Node: 24.14.1
• OS: macOS 13.7.8 (x64)
• Codex CLI: @openai/codex v0.121.0
• Model: codex/gpt-5.4
• Auth: OAuth profile (ChatGPT Plus subscription)

Steps to reproduce

1. Configure codex/gpt-5.4 as the default model with the codex plugin enabled
2. Start the gateway (openclaw gateway or LaunchAgent)
3. Open the TUI (openclaw tui) or send a message via openclaw agent --agent main --message "hello"
4. Wait for the response (arrives in ~30-40s)
5. Send a second message

Expected behavior

Second message is dispatched to the agent and a response is returned.

Actual behavior

Second message enters the session lane queue and waits indefinitely. Gateway logs show:

lane wait exceeded: lane=session:agent:main:main waitedMs=291543 queueAhead=0

queueAhead=0 confirms nothing is ahead — the lane itself is locked by the previous run.

ps aux | grep codex shows the Codex app-server process remains alive after the run. Killing the stale codex process and restarting the gateway clears the lock, but the issue recurs on the very next run.

Effective request path

TUI/Control UI → WebSocket → Gateway (ws://127.0.0.1:18888) → Agent "main" → Codex Plugin (harness) → Codex CLI app-server (stdio) → OpenAI API (https://api.openai.com/v1/responses) → gpt-5.4

Workaround

Kill stale codex processes and restart the gateway between messages:

kill <stale_codex_pid>
openclaw gateway restart

This is obviously not a viable workaround for normal use.

Notes

• The openclaw agent --agent main --message "..." CLI command completes and returns a response, but the underlying harness run never signals termination to the lane manager.
• The session lane shows waitedMs climbing continuously with queueAhead=0.
• This does not occur with the openai-codex provider (which has separate DNS/403 issues) — it is specific to the codex plugin harness route.