openclaw - 💡(How to fix) Fix Improve detection/recovery when Codex.app is running from AppTranslocation and embedded runner crashes or hangs [1 comments, 2 participants]

Summary

During investigation of OpenAI OAuth/Codex connectivity after upgrading OpenClaw from 2026.5.7 to 2026.5.18, Codex.app was initially running from a macOS AppTranslocation path. Embedded Codex runs could crash or hang, leaving OpenClaw sessions stuck in embedded_run until recovery / restart.

Moving Codex.app into /Applications and killing the old AppTranslocation processes removed one source of crashes/hangs, but this was not obvious from OpenClaw's UI/error messages.

Environment

• OpenClaw: 2026.5.18 (50a2481)
• macOS: 15.7.4
• Codex.app after move: /Applications/Codex.app, CFBundleShortVersionString=26.513.31313, CFBundleVersion=2867
• Before move, running path looked like: /private/var/folders/.../AppTranslocation/.../Codex.app/...

Crash / stuck symptoms observed

Crash reports were present immediately after Control UI-triggered embedded runs:

~/Library/Logs/DiagnosticReports/codex-2026-05-19-114211.000.ips
~/Library/Logs/DiagnosticReports/node-2026-05-19-114211.ips

The crash report indicated:

procName: codex
coalitionName: ai.openclaw.gateway
responsibleProc: node
exception: EXC_BREAKPOINT / SIGTRAP

OpenClaw logs around the same time showed a stuck embedded run:

2026-05-19T11:41:55.043+09:00 info agent/embedded strict-agentic execution contract active: runId=edd73e20-f6a7-447b-a8fe-798f46f7ad8b sessionId=58b00186-e1f5-48ab-be16-c3383ab95a56 provider=openai-codex/gpt-5.5 harness=codex configured=unspecified
2026-05-19T11:44:08.154+09:00 warn diagnostic long-running session: sessionId=58b00186-e1f5-48ab-be16-c3383ab95a56 state=processing age=121s classification=long_running activeWorkKind=embedded_run lastProgress=codex_app_server:notification:thread/tokenUsage/updated
2026-05-19T11:44:38.151+09:00 warn diagnostic stalled session: sessionId=58b00186-e1f5-48ab-be16-c3383ab95a56 state=processing age=151s classification=stalled_agent_run activeWorkKind=embedded_run lastProgress=codex_app_server:notification:thread/tokenUsage/updated
2026-05-19T11:48:08.446+09:00 warn diagnostic stuck session recovery: sessionId=58b00186-e1f5-48ab-be16-c3383ab95a56 action=abort_embedded_run aborted=true drained=true released=0

AppTranslocation process examples

Before cleanup, old Codex processes were still running from AppTranslocation even after /Applications/Codex.app existed:

/private/var/folders/.../AppTranslocation/.../Codex.app/Contents/MacOS/Codex
/private/var/folders/.../AppTranslocation/.../Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

After killing the AppTranslocation-side processes, only /Applications/Codex.app/... remained.

Expected behavior

OpenClaw should ideally detect and warn when the embedded Codex app/server is running from AppTranslocation, since this can break updates and appears to correlate with embedded runner crashes/hangs.

Possible improvements:

• Surface a clear warning in openclaw doctor / gateway health when Codex.app is translocated.
• Warn that Codex.app should be moved to /Applications and fully restarted.
• More aggressively detect dead/crashed Codex app-server subprocesses and clear stuck embedded_run state.

Impact

The user-facing symptom was that OpenAI OAuth / gpt-5.5 appeared unable to connect from Control UI, even though direct CLI runs could later succeed. The underlying issue was partly hidden by Codex app-server crash/hang and stuck session state.