#failed to parse codex app-server message

1 messages · Page 1 of 1 (latest)

rough nexus
#

After updating/migrating to the codex harness I see a flood of these messages in err.log:

2026-04-18T08:21:12.647+08:00 [agent/embedded] failed to parse codex app-server message

They don't seem fatal but my OC is very slow, and I think they're partly related.

OpenClaw 2026.4.15 (041266a)

distant dirgeBOT
naive sorrelBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

distant dirgeBOT
queen grailBOT
#

Let me verify the docs path and then I’ll trace that log line in source.

#

I found the exact warning site in the Codex harness bridge. I’m checking whether this was already hardened on newer main, because that usually tells us whether it’s harmless noise vs real protocol drift.

#

Yeah, I think they can be related.

That warning is coming from the Codex harness bridge when OpenClaw reads a line from the Codex app-server stream that is not valid JSON. On 2026.4.15, that warning site is in the bundled Codex client, so it is not just harmless generic noise.

A few useful bits:

One important detail: this specific warning is from the parser on the app-server message stream, so it points to protocol/stdout noise, not just random stderr chatter.

What I’d check next:

  1. codex --version
#

(docs require Codex app-server 0.118.0+)
2. confirm whether your model is codex/gpt-* or openai-codex/gpt-*
3. openclaw status --all
4. openclaw logs --follow and grab 20 to 30 lines around one warning

Also check whether you have any of these:

  • custom NODE_OPTIONS
  • a wrapper script around codex
  • custom plugins.entries.codex.config.appServer.command / args

Those are especially suspicious, because the bridge expects clean JSON from:

codex app-server --listen stdio://

If you want a practical workaround right now, I’d switch off the bundled Codex harness for a bit and use openai-codex/gpt-5.4 instead of codex/gpt-5.4. That keeps Codex OAuth, but avoids the new app-server harness path.

rough nexus
#

version: codex-cli 0.121.0
codex/gpt-5.4

logs... checking gateway.err.log there's nothing even closely related, just a flood of that exact message. But stops quickly.

... potential cause: I'm using a rules-based proxy, codex CLI just showed me a 403 but then recovered all by itself. I think it may have ignored the proxy first attempt, then picked up the env.vars so it routed the traffic correctly. I saw this problem briefly with re-auth.

queen grailBOT
#

Yeah, that makes the proxy theory a lot more plausible.

A few narrowed-down takeaways:

  • codex-cli 0.121.0 is fine, so this does not look like the “too old Codex app-server” case.
  • Since you’re on codex/gpt-5.4, you are definitely on the new native Codex harness path.
  • If the flood is brief, then stops, that smells like startup/auth/proxy noise during app-server init, not a persistent broken session.

One important detail from the code: OpenClaw spawns Codex with the gateway process env. So if proxy vars are only present in your interactive shell, but not in the daemon/service env, the spawned codex app-server will miss them on first launch.

So I’d check:

  1. How is the proxy injected?
    • plain HTTP_PROXY / HTTPS_PROXY
    • NODE_OPTIONS=--require ...
    • wrapper script / custom appServer.command
#

  1. Are those vars definitely present in the gateway service itself, not just your shell?

  2. After fixing env placement, do a full:

    openclaw gateway restart

My guess right now:

  • first Codex startup tries a route/auth path without the right proxy context
  • emits some non-JSON startup chatter or transient failure output
  • OpenClaw logs failed to parse codex app-server message
  • Codex retries/re-auths, then recovers

That would also fit the brief 403 you saw.

If you want, paste just these next and I can probably tell which bucket you’re in: