#Using with codex gpt5.4

10 messages · Page 1 of 1 (latest)

wary shore
#

I keep getting {"detail":"Not Found"} when trying to use openclaw with codex. I tried to use codex itself to fix this, and it proposed using ACP, which seems like a fragile hack. How are you guys doing it?

Btw, I'm on windows because I do gamedev

amber sableBOT
#

Let me check the current docs and the Codex/ACP bits specifically, because that {"detail":"Not Found"} is usually a concrete routing/config mismatch, not just “Windows being weird.”

#

Short version, there are 3 different “Codex + OpenClaw” paths, and mixing them is what usually causes the {"detail":"Not Found"} pain:

  1. OpenClaw uses Codex as its own runtime

  2. OpenClaw uses your Codex OAuth/login, but still runs through normal OpenClaw provider plumbing

  3. Codex / Claude Code / Gemini is an external harness that OpenClaw spawns or binds to a thread

#

If what you want is Codex talking to OpenClaw, do not point Codex at a raw Gateway HTTP URL. Use a bridge process:

That {"detail":"Not Found"} usually means “wrong transport / wrong endpoint”, not “ACP is broken”.

Also, on Windows, I’d strongly recommend WSL2. That’s the supported Windows path for OpenClaw, native Windows is rougher:
https://docs.openclaw.ai/platforms/windows

If you paste these, I can tell you exactly which of the 3 paths you actually want:

openclaw --version
# 
openclaw status
openclaw gateway status

and also the exact Codex command/config you’re using now.

wary shore
#

OpenClaw 2026.4.14

amber sableBOT
#

Nice, 2026.4.14 is recent enough, so this probably is not just an old-version issue.

My strong guess now is: Codex is pointed at the wrong surface.

If you currently have Codex hitting some raw http://... / ws://... Gateway URL, that would absolutely explain {"detail":"Not Found"}.

The expected setups are:

  • Codex as client to OpenClaw

    • MCP: run openclaw mcp serve
    • ACP: run openclaw acp
    • In both cases, Codex should launch a stdio bridge command, not call a random Gateway endpoint directly

  • OpenClaw using Codex internally

    • codex/gpt-5.4 = Codex harness
    • openai-codex/gpt-5.4 = Codex OAuth path
    • No ACP needed for that case
#

Also, if you’re on Windows, are you running OpenClaw in WSL2 or native Windows? That matters a lot here.

Can you paste these 3 things?

  1. your exact Codex config / command
  2. openclaw status
  3. whether OpenClaw is running in WSL2 or native Windows

If you paste the exact config snippet, I can probably tell you the fix immediately.

wary shore
#

Its native windows.
codex config:

"openai-codex:default": {
81 "provider": "openai-codex",
82 - "mode": "oauth",
83 },

status overview pt 1
│ Item │ Value │
├──────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────┤
│ OS │ windows 10.0.26200 (x64) · node 23.6.0 │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.14 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 29ms · auth token · localsvr (192. │
│ │ 168.0.140) app 2026.4.14 windows 10.0.26200 │
│ Gateway self │ localsvr (192.168.0.140) app 2026.4.14 windows 10.0.26200 │
│ Gateway service │ Scheduled Task not installed │

amber sableBOT
#

That helps a lot.

From what you pasted, the Gateway itself looks healthy. So I don’t think this is a basic OpenClaw-up / OpenClaw-down problem.

The important bit is this:

  • openai-codex:default is just your auth profile
  • it does not mean the Codex harness is configured
  • it also does not mean a Codex client is correctly bridged into OpenClaw

So my read is: you’ve probably got the right auth, but the wrong integration path.

What I’d do next:

  1. If your goal is “use Codex as the model inside OpenClaw”
    • use openai-codex/gpt-5.4 for Codex OAuth, or
    • use codex/gpt-5.4 for the Codex harness