hasty pebble
Running on nssm
Tried to manually install codex.cmd (not sure why I need to do that)
Set it's environment variable as follows OPENCLAW_CODEX_APP_SERVER_BIN=<PATH>
Still getting the same error below.
hello
run error: Managed Codex app-server binary was not found for @openai/codex. Reinstall or update OpenClaw, or run pnpm
install in a source checkout. Set plugins.entries.codex.config.appServer.command or OPENCLAW_CODEX_APP_SERVER_BIN to use
a custom Cod...
connected | error
agent main
near portalBOT
noble waspBOT
Running on nssm
Tried to manually install codex.cmd (not sure why I need to do t...
Bob S, first thing: can you paste openclaw --version? Version mismatch is a common cause here.
I checked the current Codex harness docs/source. That error means OpenClaw is still trying the managed bundled Codex binary and cannot find it. If OPENCLAW_CODEX_APP_SERVER_BIN were being read, the command source would be treated as an explicit env override, so the most likely issue is that the NSSM service process is not seeing that env var.
On Windows/NSSM I’d avoid relying on an interactive shell env var and set the override in OpenClaw config instead:
{
plugins: {
entries: {
codex: {
enabled: true,
config: {
appServer: {
command: "C:\\path\\to\\codex.cmd"
}
}
}
}
}
}
Then fully restart the NSSM service and start a fresh chat/session with /new or /reset.
A few checks:
codex.cmd, not just a folder."C:\\path\\to\\codex.cmd" app-server --listen stdio:// should at least start rather than “command not found”.Docs I checked: https://docs.openclaw.ai/plugins/codex-harness and https://docs.openclaw.ai/plugins/codex-harness-reference.
hasty pebble
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows
PS C:\windows\system32> openclaw --version
OpenClaw 2026.5.12 (f066dd2)
PS C:\windows\system32>
noble waspBOT
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
In...
Thanks Bob S. I checked the exact 2026.5.12 source. That build does support both overrides:
OPENCLAW_CODEX_APP_SERVER_BINplugins.entries.codex.config.appServer.commandSo if the error still says “Managed Codex app-server binary was not found”, OpenClaw has not picked up either override and is still using the bundled/managed path.
For NSSM, I’d use the config override because it’s less ambiguous than service env inheritance:
{
plugins: {
entries: {
codex: {
enabled: true,
config: {
appServer: {
command: "C:\\Users\\YOURUSER\\AppData\\Roaming\
pm\\codex.cmd"
}
}
}
}
}
}
Then:
/new or /reset in this Discord thread before testing again.openclaw status --all and check which config path the service actually loaded. NSSM often runs from C:\Windows\System32, so it may not be reading the config file you edited.
noble waspBOT
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
In...
Also worth checking from PowerShell:
where.exe codex
codex.cmd app-server --listen stdio://
The first gives the exact path to put in config. The second verifies the Codex install can start the app-server.
Docs: https://docs.openclaw.ai/plugins/codex-harness-reference
hasty pebble
No its hanging... I have no idea why I have to mess with this new codex server.. no docs said anything about it... doctor fix does not do anything?
PS C:\windows\system32> openclaw --version
OpenClaw 2026.5.12 (f066dd2)
PS C:\windows\system32> where.exe codex
C:\Users\bobbo\AppData\Roaming\npm\codex
C:\Users\bobbo\AppData\Roaming\npm\codex.cmd
PS C:\windows\system32> codex.cmd app-server --listen stdio://
noble waspBOT
No its hanging... I have no idea why I have to mess with this new codex server.....
Bob S, that codex.cmd app-server --listen stdio:// “hang” is actually expected: stdio mode starts a server and waits for JSON-RPC on stdin/stdout. It won’t print a friendly “ready” line.
The annoying part is real though: you normally should not have to manually care about this. In 5.12 the Codex harness expects a managed @openai/codex binary bundled/installed with the Codex plugin. doctor --fix repairs config/state, but it does not necessarily reinstall missing npm package contents for the bundled Codex app-server.
Given your output, use this exact override path:
{
plugins: {
entries: {
codex: {
enabled: true,
config: {
appServer: {
command: "C:\\Users\\bobbo\\AppData\\Roaming\
pm\\codex.cmd"
}
}
}
}
}
}
Then fully restart the NSSM service and test in a new/reset session.
If it still says Managed Codex app-server binary was not found, then the service is not reading that config. Run:
openclaw status --all
and look for the config path / service details. Since your shell prompt is C:\windows\system32, NSSM may be running OpenClaw with a different working directory/config than the one you edited.
If the error changes from “managed binary not found” to an auth/runtime error, that is progress and means the command override is being picked up.
hasty pebble
still hanging on tui inquiry (after config.json edit)
hello again?
run error: codex.cmd wrapper resolved, but no executable/Node entrypoint could be resolved without shell execution.
connected | error
agent main (Bob Bot) | session main (openclaw-tui) | openai/gpt-5.5 | think xhigh | verbose on | tokens 65k/272k (24%)
noble waspBOT
still hanging on tui inquiry (after config.json edit)
hello again?
run error...
Bob S, good, that means the config edit is now being picked up. The new failure is Windows-specific: OpenClaw refuses to spawn .cmd wrappers through a shell for this path, and it could not resolve the wrapper to the real Node entrypoint.
Point appServer.command at the JS entrypoint instead of codex.cmd:
{
plugins: {
entries: {
codex: {
enabled: true,
config: {
appServer: {
command: "C:\\Users\\bobbo\\AppData\\Roaming\
pm\
ode_modules\\@openai\\codex\\bin\\codex.js"
}
}
}
}
}
}
Then restart NSSM and /new or /reset.
Before restarting, verify that file exists:
Test-Path "C:\Users\bobbo\AppData\Roaming
pm
ode_modules\@openai\codex\bin\codex.js"
If that returns False, run:
npm root -g
and use:
<that path>\@openai\codex\bin\codex.js
I agree this is too much manual plumbing. From the 5.12 source, managed Codex should normally find its bundled @openai/codex; your install looks like it’s missing that managed binary, then the Windows wrapper fallback is hitting a hardening rule. If the JS-entrypoint workaround gets you unstuck, I’d still file this as a bug so the Windows/NSSM path can be fixed properly: https://github.com/openclaw/openclaw/issues
hasty pebble
Still hanging, now on gateway connecting.. is this needed?
"args": ["app-server"]
noble waspBOT
Still hanging, now on gateway connecting.. is this needed?
"args": ["app-server...
Bob S, don’t set args: ["app-server"] by itself.
If args is unset, OpenClaw uses the default:
args: ["app-server", "--listen", "stdio://"]
If you do set args, it replaces the default. So either remove args entirely, or set the full version:
{
plugins: {
entries: {
codex: {
enabled: true,
config: {
appServer: {
command: "C:\\Users\\bobbo\\AppData\\Roaming\
pm\
ode_modules\\@openai\\codex\\bin\\codex.js",
args: ["app-server", "--listen", "stdio://"]
}
}
}
}
}
}
I’d prefer removing args first and only keeping command.
noble waspBOT
Still hanging, now on gateway connecting.. is this needed?
"args": ["app-server...
Also, “gateway connecting” sounds like the service may now be stuck starting or the TUI cannot reach it. After the edit, fully restart NSSM, then run:
openclaw gateway status
openclaw logs --follow
If logs show a new Codex error, paste that. If the gateway itself is not reachable, this has moved from Codex command resolution to service startup/config loading.
hasty pebble
logs are not moving upon tui trying to connect to gateway and hanging
noble waspBOT
logs are not moving upon tui trying to connect to gateway and hanging
Bob S, if the TUI is hanging at “connecting to gateway” and openclaw logs --follow does not move, then we’re probably not reaching a live gateway process. That’s now before the Codex turn path.
Check these in PowerShell:
openclaw gateway status
openclaw health --verbose
If the NSSM service says it is running but health cannot connect, restart it once. If it still hangs, temporarily stop NSSM and run the gateway in the foreground so config/startup errors are visible:
openclaw gateway
Leave that window open, then in a second PowerShell run:
noble waspBOT
logs are not moving upon tui trying to connect to gateway and hanging
openclaw health --verbose
openclaw tui
If foreground gateway prints a config parse error, paste that. If foreground gateway works, the issue is likely NSSM service context: wrong working directory, wrong env, or reading a different config path than the one you edited.
Also double-check your JSON5 shape after the edit. A bad comma/quote can keep the service from starting, and NSSM can make that look like “connecting forever” instead of a clean config error.
hasty pebble
it's still hanging, try a deeper diagnostic before the next recommendation
noble waspBOT
it's still hanging, try a deeper diagnostic before the next recommendation
Bob S, agreed. Stop changing Codex config for the moment; we need to split gateway dead/unreachable from gateway alive but TUI handshake stuck.
I can’t probe your Windows host directly from here, so please run this exact diagnostic bundle and paste the output/error text:
openclaw gateway status --deep
openclaw health --verbose
openclaw status --all
openclaw logs --limit 120 --plain --local-time
Then check whether anything is actually listening on the default gateway port:
netstat -ano | findstr :18789
What I’m looking for:
gateway status --deep tells us whether NSSM/service runtime and CLI probe agree.health --verbose shows the exact URL/config path the CLI is trying.status --all includes service/config/version mismatch diagnostics.logs --limit is better than --follow here because --follow can look idle when the gateway RPC path is wedged.netstat tells us whether a process owns the gateway port at all.If gateway status --deep hangs too, say that specifically and run this variant so we can see whether it is a CLI probe timeout vs a hard process hang:
openclaw gateway status --deep --timeout 5000
Docs for this ladder: https://docs.openclaw.ai/gateway/troubleshooting and https://docs.openclaw.ai/cli/status
hasty pebble
PS C:\windows\system32> openclaw gateway status --deep --timeout 5000
🦞 OpenClaw 2026.5.12 (f066dd2) — I've seen your commit messages. We'll work on that together.
|
o
Service: Scheduled Task (registered)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-05-16.log
Command: C:\Program Files\nodejs\node.exe C:\Users\bobbo\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_GATEWAY_PORT=18789
Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json
Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.
CLI version: 2026.5.12 (~\AppData\Roaming\npm\node_modules\openclaw\openclaw.mjs)
Gateway version: 2026.5.12
Runtime: running (pid 32436, state Ready, last run -1073741510, last run time 5/16/2026 12:43:04 PM, Verified gateway listener detected on port 18789 even though schtasks did not report a running task.)
Connectivity probe: ok
Capability: admin-capable
Listening: 127.0.0.1:18789
Other gateway-like services detected (best effort):
noble waspBOT
PS C:\windows\system32> openclaw gateway status --deep --timeout 5000
🦞 OpenCl...
Bob S, this output is useful: the gateway itself is not dead.
Key bits:
Connectivity probe: okCapability: admin-capableListening: 127.0.0.1:187892026.5.12So the TUI “connecting to gateway” hang is probably not TCP/WebSocket reachability. It’s more likely hanging after connect while loading startup state/history, or you have a stale/orphan gateway process: status says the scheduled task is Ready, but a verified gateway listener is still running on pid 32436.
Next diagnostic, not a config change:
openclaw health --verbose
openclaw logs --limit 200 --plain --local-time
openclaw status --all
If those return normally, then try forcing the TUI to the exact healthy endpoint:
openclaw tui --url ws://127.0.0.1:18789
If that still hangs, the gateway is accepting clients but the TUI startup request path is wedged. In that case I’d do one clean service/process realignment:
openclaw gateway restart
openclaw gateway status --deep --timeout 5000
The weird part is the scheduled task/listener mismatch. If restart doesn’t bring the scheduled task and listener into agreement, that’s worth including in a GitHub issue with this status output.
hasty pebble
PS C:\windows\system32> openclaw health --verbose
🦞 OpenClaw 2026.5.12 (f066dd2) — Type the command with confidence—nature will provide the stack trace if needed.
|
o
Gateway connection:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\bobbo.openclaw\openclaw.json
Bind: loopback
Microsoft Teams: configured
Gateway event loop: ok max=35ms p99=35ms util=0.182 cpu=0.215
Agents: main (default), fintech, devopsbot, cashclaw, gtm, game, ux, apibot, dbbot, flutterbot
Heartbeat interval: 30m (main), 30m (fintech), 30m (devopsbot), 30m (cashclaw), 30m (gtm), 30m (game), 30m (ux), 30m (apibot), 30m (dbbot), 30m (flutterbot)
Session store (main): C:\Users\bobbo.openclaw\agents\main\sessions\sessions.json (34 entries)
noble waspBOT
PS C:\windows\system32> openclaw health --verbose
🦞 OpenClaw 2026.5.12 (f066dd...
Bob S, health confirms the gateway and event loop are healthy. That narrows this to TUI startup state, not the gateway port.
The health output shows agent:main:main was touched ~22m ago, which lines up with the failing TUI session. The TUI loads history on attach, so test whether the hang is tied to that session/history:
openclaw tui --url ws://127.0.0.1:18789 --session diag-fresh --history-limit 5
If that opens, the gateway is fine and the problem is probably the existing main session/run state. Then use a fresh session for now, or reset the old one from inside TUI/Discord with /reset once the UI is responsive.
If even diag-fresh --history-limit 5 hangs, paste the last ~200 lines from:
openclaw logs --limit 200 --plain --local-time
At that point I’d be looking for TUI chat.history, sessions.list, or auth/connect warnings rather than more Codex command config.
hasty pebble
Will the next openclaw version fix this issue... should I just wait for that?
noble waspBOT
Will the next openclaw version fix this issue... should I just wait for that?
Short answer: I would update rather than keep digging on 5.12, but I can’t promise it fixes every part of what you’re seeing.
I checked what landed after 2026.5.12 (f066dd2). There are several relevant fixes on newer builds:
That matches the shape of your symptoms better than more config tweaking. The one thing I did not see as an obvious “Bob’s exact Windows .cmd wrapper path” fix, so if the managed binary / Windows shim problem persists after updating, it should become a GitHub issue with your status output and the codex.cmd wrapper resolved... error: https://github.com/openclaw/openclaw/issues
My recommendation:
main session:
noble waspBOT
Will the next openclaw version fix this issue... should I just wait for that?
openclaw update
openclaw gateway restart
openclaw gateway status --deep --timeout 5000
openclaw tui --url ws://127.0.0.1:18789 --session diag-fresh --history-limit 5
If the updated version restores the managed Codex binary, you may be able to remove the custom plugins.entries.codex.config.appServer.command override afterward.
hasty pebble
Now getting this after TUI connects, trying to chat
hello
run error: codex app-server exited: code=1 signal=null stderr="node:internal/modules/cjs/loader:1451 throw err; ^
Error: Cannot find module 'C:\Users\bobbo\AppData\Roaming pm\node_modules\@openai\codex\bin\codex.js' at
Module._resolveFilename...
noble waspBOT
Now getting this after TUI connects, trying to chat
hello
run error: codex a...
Bob S, that error is now very specific: the configured path is malformed.
It is trying to load:
C:\Users\bobbo\AppData\Roaming pm
ode_modules\@openai\codex\bin\codex.js
That Roaming pm means the in pm was interpreted as a newline/escape. In JSON/JSON5 config, Windows backslashes must be escaped, or use forward slashes.
Use one of these forms:
command: "C:\\Users\\bobbo\\AppData\\Roaming\
pm\
ode_modules\\@openai\\codex\\bin\\codex.js"
or simpler:
command: "C:/Users/bobbo/AppData/Roaming/npm/node_modules/@openai/codex/bin/codex.js"
I’d use the forward-slash version to avoid escape mistakes.
Then verify the file exists:
noble waspBOT
Now getting this after TUI connects, trying to chat
hello
run error: codex a...
Test-Path "C:/Users/bobbo/AppData/Roaming/npm/node_modules/@openai/codex/bin/codex.js"
If that returns True, restart the gateway and try again. If it returns False, run:
npm root -g
and build the same forward-slash path from that output.
hasty pebble
OK path to js was wrong, now fixed, still getting hang condition past tui connection, but on first chat
noble waspBOT
OK path to js was wrong, now fixed, still getting hang condition past tui connec...
Bob S, that means we’re past the path/launcher problem. Now the first chat is likely hanging inside the Codex app-server turn itself.
Please grab logs immediately after sending the hanging first chat:
openclaw logs --limit 250 --plain --local-time
openclaw gateway status --deep --timeout 5000
Also check whether a Codex child process is sitting there:
Get-CimInstance Win32_Process |
Where-Object { $_.CommandLine -match "codex|app-server|@openai" } |
Select-Object ProcessId, CommandLine
What I’m looking for:
turnCompletionIdleTimeout, app-server request watchdog, or app-server stderr, it’s a Codex runtime stall.One quick isolation test: temporarily switch the agent to a non-Codex runtime/model or disable the Codex plugin and try one TUI message. If PI/direct runtime replies, the TUI/gateway/session are fine and the remaining bug is specifically Codex app-server on Windows.
If you already updated after the earlier message, paste the new openclaw --version too.
hasty pebble
}. Please try again or re-authenticate."
2026-05-16T13:14:32.928-04:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"6193c398-f1bc-4db4-878b-f2a83614e407","sessionId":"de306acc-639e-4e88-afb1-149c4fa70d88","lane":"main","decision":"candidate_failed","requestedProvider":"openai","requestedModel":"gpt-5.5","candidateProvider":"openai","candidateModel":"gpt-5.5","attempt":1,"total":1,"reason":"auth_permanent","status":403,"errorPreview":"OAuth token refresh failed for openai-codex: OpenAI Codex token refresh failed (401): {\n "error": {\n "message": "Could not validate your token. Please try signing in again.",\n "type": "invalid_request_error",\n "param": null,\n "code": "token_expired"\n }\n}. Please try again or re-authenticate.","errorHash":"sha256:4f8371c16ebd","fallbackStepType":"fallback_step","fallbackStepFromModel":"openai/gpt-5.5","fallbackStepFromFailureReason":"auth_permanent","fallbackStepFromFailureDetail":"OAuth token refresh failed for openai-codex: OpenAI Codex token refresh failed (401): {\n "error": {\n "message": "Could not validate your token. Please try signing in again.",\n "type": "invalid_request_error",\n "param": null,\n "code": "token_expired"\n }\n}. Please try again or re-authenticate.","fallbackStepChainPosition":1,"fallbackStepFinalOutcome":"chain_exhausted","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":false} model fallback decision
2026-05-16T13:14:34.160-04:00 error Embedded agent failed before reply: OAuth token refresh failed for openai-codex: OpenAI Codex token refresh failed (401): {
"error": {
"message": "Could not validate your token. Please try signing in again.",
"type": "invalid_request_error",
"param": null,
"code": "token_expired"
}
}
noble waspBOT
}. Please try again or re-authenticate."
2026-05-16T13:14:32.928-04:00 warn mode...
Bob S, that log finally identifies the current blocker: this is no longer a launcher/path hang. Your Codex OAuth token is expired/invalid:
OAuth token refresh failed for openai-codex
code: token_expired
Could not validate your token. Please try signing in again.
Re-auth Codex on the gateway host:
openclaw models auth list --provider openai-codex
openclaw models auth login --provider openai-codex
openclaw models status --probe --probe-provider openai-codex
openclaw gateway restart
Then test a fresh TUI session again.
If you have multiple agents and the failing one is main, also check the agent-scoped profile list:
openclaw models auth list --agent main --provider openai-codex
If it shows an old/stale profile still being selected after login, run openclaw doctor --fix once after the new login and restart again.
Docs: https://docs.openclaw.ai/providers/openai and https://docs.openclaw.ai/plugins/codex-harness
hasty pebble
probing auth profiles hangs too
PS C:\windows\system32> openclaw models status --probe --probe-provider openai-codex
🦞 OpenClaw 2026.5.12 (f066dd2) — I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.
|
• Probing auth profiles…
noble waspBOT
probing auth profiles hangs too
PS C:\windows\system32> openclaw models status ...
Bob S, don’t use the probe right now. It’s hitting the same expired-token refresh path and hanging while trying to validate it.
Do the non-probe list + fresh login path instead:
openclaw models auth list --provider openai-codex
openclaw models auth login --provider openai-codex
openclaw gateway restart
Then test chat. Only run the probe after the login has completed successfully.
If models auth login --provider openai-codex itself hangs, try the browser/device-code variant from the OpenAI provider docs:
openclaw models auth login --provider openai-codex --device-code
If list/login show an old profile still winning, paste the output of the list command. Don’t paste tokens/secrets, but profile ids and status labels are fine.
hasty pebble
OpenAI OAuth complete
Config overwrite: C:\Users\bobbo.openclaw\openclaw.json (sha256 2eace1282282934777f09ccaaa87c655c3542cf713e48c38eba5abb3a59d4ca2 -> cdfc8c2f3308a59a1cc5357d4fb77c27bfa25c0af595688ca5b5beb5fb49476e, backup=C:\Users\bobbo.openclaw\openclaw.json.bak)
Updated ~.openclaw\openclaw.json
Auth profile: openai-codex:bsavino@outlook.com (openai-codex/oauth)
Default model available: openai/gpt-5.5 (use --set-default to apply)
Tip: Codex-capable models can use native Codex web search. Enable it with openclaw configure --section web (recommended mode: cached). Docs: https://docs.openclaw.ai/tools/web
then this hangs though
noble waspBOT
OpenAI OAuth complete
Config overwrite: C:\Users\bobbo\.openclaw\openclaw.json (...
Good, that fixes the expired Codex OAuth profile.
Now restart the gateway so the running service reloads the new auth/config, then test a fresh TUI session:
openclaw gateway restart
openclaw gateway status --deep --timeout 5000
openclaw tui --url ws://127.0.0.1:18789 --session diag-fresh --history-limit 5
If the chat works, then the remaining cleanup is optional:
plugins.entries.codex.config.appServer.command override later if an updated OpenClaw build restores the managed Codex binary path
noble waspBOT
then this hangs though
Which command is hanging: openclaw gateway restart, gateway status, or the tui command?
If it’s openclaw gateway restart, don’t wait on it forever. Open a second PowerShell and run:
openclaw gateway status --deep --timeout 5000
openclaw health --verbose
openclaw logs --limit 200 --plain --local-time
That will tell us whether the restart actually completed and only the CLI is stuck waiting, versus the gateway failing to come back.
If restart is the stuck step, this is also useful on Windows because your earlier status showed a scheduled-task/listener mismatch:
netstat -ano | findstr :18789
If there’s still a listener and health is OK, try the fresh TUI command anyway. If there’s no listener or health fails, paste the last log lines.
hasty pebble
PS C:\windows\system32> openclaw gateway status --deep --timeout 5000
|
o
Service: Scheduled Task (registered)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-05-16.log
Command: C:\Program Files\nodejs\node.exe C:\Users\bobbo\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_GATEWAY_PORT=18789
Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json
Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.
Runtime: running (pid 9020, state Ready, last run 0, last run time 5/16/2026 1:02:03 PM, Verified gateway listener detected on port 18789 even though schtasks did not report a running task.)
Connectivity probe: ok
Capability: admin-capable
Listening: 127.0.0.1:18789
Other gateway-like services detected (best effort):
Recommendation: run a single gateway per machine for most setups. One gateway supports multiple agents (see docs: /gateway#multiple-gateways-same-host).
If you need multiple gateways (e.g., a rescue bot on the same host), isolate ports + config/state (see docs: /gateway#multiple-gateways-same-host).
noble waspBOT
PS C:\windows\system32> openclaw gateway status --deep --timeout 5000
|
o
Serv...
Bob S, this status says the gateway is reachable, but the process is still in that odd scheduled-task/listener mismatch state. Also, if the OAuth login happened after this gateway process started, the running gateway may not have reloaded the new profile yet.
Try the bounded restart escape hatch, not the default restart:
openclaw gateway restart --force --wait 30s
openclaw gateway status --deep --timeout 5000
If restart --force --wait 30s itself hangs or errors, paste that exact output. Don’t delete the scheduled task yet.
After the restart, confirm the status shows a new last run time and then test:
openclaw tui --url ws://127.0.0.1:18789 --session diag-fresh --history-limit 5
If the gateway status still reports “listener detected even though schtasks did not report a running task” after a forced restart, that service supervision mismatch is probably the root of the reload weirdness and belongs in the GitHub issue with this status block.
hasty pebble
if I'm running nssm, doesn't this need to be off (I believe it was off before?)
\OpenClaw Gateway (system, task: \OpenClaw Gateway, run: C:\Users\bobbo.openclaw\gateway.cmd)
noble waspBOT
if I'm running nssm, doesn't this need to be off (I believe it was off before?)
...
Yes. If NSSM is supposed to own the gateway, that scheduled task should not also be supervising C:\Users\bobbo\.openclaw\gateway.cmd.
That status output strongly suggests you have two supervision paths fighting or leaving an orphan listener:
\OpenClaw GatewayI would disable, not delete, the scheduled task first so it’s reversible:
schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
schtasks /Change /TN "OpenClaw Gateway" /Disable
Then restart only the NSSM service, and verify:
openclaw gateway status --deep --timeout 5000
Healthy target state:
127.0.0.1:18789If NSSM is definitely the intended install, don’t use openclaw gateway restart until this is cleaned up, because OpenClaw is currently detecting the scheduled-task install and may be restarting the wrong supervisor.
hasty pebble
why did it RE-ENABLE THIS SCHEDULED TASK..did the upgrade do this?
noble waspBOT
why did it RE-ENABLE THIS SCHEDULED TASK..did the upgrade do this?
Yeah, your suspicion is reasonable.
I checked the 5.12 docs/source behavior: openclaw update says that when a local managed Gateway service is installed, it stops/restarts it and refreshes service metadata from the updated install. On Windows, OpenClaw’s managed service is the Scheduled Task path. So if that old OpenClaw Gateway task still existed, the update/restart flow could absolutely treat it as the managed gateway and bring it back, even if you personally intended NSSM to be the real supervisor.
So the likely story is:
If you want NSSM only, disable or remove the OpenClaw scheduled task and avoid openclaw gateway install/restart until the supervisor situation is clean.
Reversible first:
schtasks /Change /TN "OpenClaw Gateway" /Disable
If you’re confident NSSM owns it and you don’t want OpenClaw’s scheduled task at all:
schtasks /Delete /TN "OpenClaw Gateway" /F
Then restart via NSSM only, and use openclaw gateway status --deep --timeout 5000 to confirm there’s one listener. Going forward, use openclaw update --no-restart if you want to prevent OpenClaw’s updater from touching the managed service and handle the NSSM restart yourself.
hasty pebble
thats probably all the hanging then?
noble waspBOT
thats probably all the hanging then?
Probably a big part of it, yes.
You had at least three separate blockers layered together:
codex.cmd / JS path issuesopenai-codex OAuthThe supervisor conflict is especially likely to explain the “restart hangs / config not reloaded / gateway looks alive but behavior doesn’t change” weirdness. One process can keep listening on 18789 while the service you think you restarted is not actually the one serving requests.
Clean target state:
openclaw gateway status --deep shows one listener and no extra OpenClaw Gateway task
noble waspBOT
thats probably all the hanging then?
After that, if the first chat still hangs, it’s much narrower: likely Codex app-server runtime itself, and the logs should show a real Codex/auth error instead of all this service drift noise.
hasty pebble
getting further but still errors
2026-05-16T13:45:25.043-04:00 debug plugins {"subsystem":"plugins"} [plugins] loading codex from C:\Users\bobbo.openclaw\npm\node_modules@openclaw\codex\dist\index.js
2026-05-16T13:45:25.046-04:00 debug plugins {"subsystem":"plugins"} [plugins] loaded 1 plugin(s) (1 attempted) in 3.3ms
2026-05-16T13:46:22.921-04:00 error gateway connect failed: Error: gateway closed (1000):
2026-05-16T13:46:22.924-04:00 error gateway connect failed: Error: gateway closed (1000):
2026-05-16T13:46:26.315-04:00 debug plugins {"subsystem":"plugins"} [plugins] loading openai from C:\Users\bobbo\AppData\Roaming\npm\node_modules\openclaw\dist\extensions\openai\index.js
2026-05-16T13:46:26.318-04:00 debug plugins {"subsystem":"plugins"} [plugins] loaded 1 plugin(s) (1 attempted) in 3.2ms
2026-05-16T13:47:47.208-04:00 debug gateway client error: Error: WebSocket was closed before the connection was established
Log tail truncated (increase --max-bytes).
PS C:\windows\system32>er but still errors
tui chat still hanging too
noble waspBOT
getting further but still errors
2026-05-16T13:45:25.043-04:00 debug plugins {"...
That snippet doesn’t show the actual run failure yet. gateway closed (1000) is a normal WebSocket close code, so it may just be a client/TUI reconnect symptom. The important line is also truncated.
Two things I notice:
codex is loading from C:\Users\bobbo\.openclaw pm ode_modules\@openclaw\codexopenai is loading from the global OpenClaw install under AppData\Roaming pm ode_modules\openclaw\dist\extensionsThat can be valid, but after this much service/update churn I’d want to rule out stale plugin/package state.
Please run:
openclaw logs --limit 500 --max-bytes 1000000 --plain --local-time
openclaw plugins list
openclaw gateway status --deep --timeout 5000
For the logs, paste the first error after the chat attempt plus ~20 lines before/after it. The current tail starts after the useful part.
If openclaw plugins list reports stale/corrupt/offline plugin state for codex, run:
openclaw doctor --fix
then restart via NSSM only, not openclaw gateway restart, since you’re trying to keep the scheduled task out of the loop.
hasty pebble
and this has returned
. Please try again or re-authenticate."
2026-05-16T13:48:55.346-04:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"60070596-1ba9-4377-87b6-8733492fc474","sessionId":"de306acc-639e-4e88-afb1-149c4fa70d88","lane":"main","decision":"candidate_failed","requestedProvider":"openai","requestedModel":"gpt-5.5","candidateProvider":"openai","candidateModel":"gpt-5.5","attempt":1,"total":1,"reason":"auth_permanent","status":403,"errorPreview":"OAuth token refresh failed for openai-codex: OpenAI Codex token refresh failed (401): {\n "error": {\n "message": "Could not validate your token. Please try signing in again.",\n "type": "invalid_request_error",\n "param": null,\n "code": "token_expired"\n }\n}. Please try again or re-authenticate.","errorHash":"sha256:4f8371c16ebd","fallbackStepType":"fallback_step","fallbackStepFromModel":"openai/gpt-5.5","fallbackStepFromFailureReason":"auth_permanent","fallbackStepFromFailureDetail":"OAuth token refresh failed for openai-codex: OpenAI Codex token refresh failed (401): {\n "error": {\n "message": "Could not validate your token. Please try signing in again.",\n "type": "invalid_request_error",\n "param": null,\n "code": "token_expired"\n }\n}. Please try again or re-authenticate.","fallbackStepChainPosition":1,"fallbackStepFinalOutcome":"chain_exhausted","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":false} model fallback decision
2026-05-16T13:48:56.843-04:00 error Embedded agent failed before reply: OAuth token refresh failed for openai-codex: OpenAI Codex token refresh failed (401): {
"error": {
"message": "Could not validate your token. Please try signing in again.",
"type": "invalid_request_error",
"param": null,
"code": "token_expired"
noble waspBOT
tui chat still hanging too
At this point I’d isolate TUI from the agent runtime. Try a non-TUI chat call against the same gateway:
openclaw agent --message "hello" --timeout 60
If that also hangs/fails, the TUI is not the problem; it’s the gateway → Codex/app-server run path. Then the next useful evidence is the full log around that one command:
openclaw logs --limit 500 --max-bytes 1000000 --plain --local-time
If openclaw agent --message "hello" works but TUI chat hangs, then it’s specifically TUI/session/history/client state. In that case test with:
openclaw tui --url ws://127.0.0.1:18789 --session totally-new-test --history-limit 0 --timeout-ms 60000
Given we’ve already uncovered service supervisor drift, stale Codex launcher config, and expired OAuth, I’d also seriously consider filing this now with the full timeline. The Windows/NSSM + scheduled-task reactivation + managed Codex binary failure is enough for a strong bug report: https://github.com/openclaw/openclaw/issues
noble waspBOT
and this has returned
. Please try again or re-authenticate."
2026-05-16T13:4...
That means the running selection is still using an expired openai-codex credential, not the fresh one you just created. The fresh profile is:
openai-codex:bsavino@outlook.com
Force the auth order to that profile so OpenAI/Codex runs stop picking the stale one:
openclaw config get auth.order --json
openclaw config set auth.order.openai '["openai-codex:bsavino@outlook.com"]' --strict-json
openclaw config set auth.order.openai-codex '["openai-codex:bsavino@outlook.com"]' --strict-json
Then restart via NSSM only and test again.
noble waspBOT
and this has returned
. Please try again or re-authenticate."
2026-05-16T13:4...
Also run this and check whether an old profile is still listed before the new one:
openclaw models auth list --provider openai-codex
openclaw models auth list --agent main --provider openai-codex
If --agent main shows a different stale profile, that’s likely the exact reason the gateway keeps using the expired token. In newer code there are fixes around rewriting invalidated per-agent Codex order to the main agent’s healthy relogin profile, but on 5.12 you may need to force the order explicitly as above.
hasty pebble
the auth process is hanging at the end, cannot exit, perhaps it's not committing right?
PS C:\windows\system32> openclaw agent --message "hello" --timeout 60
🦞 OpenClaw 2026.5.12 (f066dd2) — I've read more man pages than any human should—so you don't have to.
Error: No target session selected. Use --agent <id>, --session-id <id>, or --to <E.164>. Run openclaw agents list to see agents.
PS C:\windows\system32>
noble waspBOT
the auth process is hanging at the end, cannot exit, perhaps it's not committing...
Yes, that’s plausible, but the output you pasted already showed the important writes completed:
Config overwrite...
Updated ~\.openclaw\openclaw.json
Auth profile: openai-codex:bsavino@outlook.com
So if it hangs after those lines, it may be stuck in post-login cleanup/probing rather than failing to write.
I’d do this:
Ctrl+C once to exit the hung auth command.openclaw models auth list --provider openai-codex
openclaw config get auth.order --json
openclaw config set auth.order.openai '["openai-codex:bsavino@outlook.com"]' --strict-json
openclaw config set auth.order.openai-codex '["openai-codex:bsavino@outlook.com"]' --strict-json
Then restart via NSSM only.
If models auth list does not show the new profile after Ctrl+C, then the login command is hanging before the auth store commit even though config wrote. In that case try:
noble waspBOT
the auth process is hanging at the end, cannot exit, perhaps it's not committing...
openclaw models auth login --provider openai-codex --device-code
But based on your pasted “Auth profile:” line, I expect it did commit and the hang is after the useful part.
noble waspBOT
PS C:\windows\system32> openclaw agent --message "hello" --timeout 60
🦞 OpenCl...
My bad, that command needs an explicit target in your setup. Use the main agent/session:
openclaw agent --agent main --session-id diag-cli --message "hello" --timeout 60
If that still complains, run:
openclaw agents list
and use the exact agent id shown there.
This is just an isolation test: if CLI agent hangs/fails with the same OAuth error, TUI is not the root problem. If CLI agent works and TUI hangs, then we focus on TUI/session state.
hasty pebble
PS C:\windows\system32> openclaw models auth list --provider openai-codex
🦞 OpenClaw 2026.5.12 (f066dd2) — Your AI assistant, now without the $3,499 headset.
Agent: main
Auth state file: ~.openclaw\agents\main\agent\auth-state.json
Provider: openai-codex
Profiles:
noble waspBOT
PS C:\windows\system32> openclaw models auth list --provider openai-codex
🦞 Op...
Good. The new profile is committed in the main agent auth store and is not expired.
Now make sure the running gateway is selecting it, not some stale cached/order value:
openclaw config get auth.order --json
openclaw models auth list --agent main --provider openai-codex
If auth.order is empty/missing, set it explicitly anyway:
openclaw config set auth.order.openai '["openai-codex:bsavino@outlook.com"]' --strict-json
openclaw config set auth.order.openai-codex '["openai-codex:bsavino@outlook.com"]' --strict-json
Then restart NSSM only. Since the scheduled task was interfering, do not use openclaw gateway restart for this test.
noble waspBOT
PS C:\windows\system32> openclaw models auth list --provider openai-codex
🦞 Op...
After NSSM restart:
openclaw gateway status --deep --timeout 5000
openclaw agent --agent main --session-id diag-cli --message "hello" --timeout 60
If it still says token_expired after that, the gateway process is not loading the auth state file you just listed, or it is holding stale auth in memory despite restart.
hasty pebble
how do you know that auth is new, it expires 10 days from now?
noble waspBOT
how do you know that auth is new, it expires 10 days from now?
Because of the sequence and the timestamp.
You pasted the OAuth completion just now for:
Auth profile: openai-codex:bsavino@outlook.com
Then models auth list shows exactly that profile with:
expires 2026-05-26T17:51:16.968Z
Today is 2026-05-16, so that expiry was issued around the time you completed login. A 10-day expiry is normal-looking for an OAuth access/refresh state display; it doesn’t mean the login is old.
The confusing bit is your run log still says token_expired, which means the run path is not using this freshly listed profile, or it is using stale in-memory auth from before the NSSM/scheduled-task cleanup. That’s why I’m pushing toward explicit auth.order + a clean NSSM-only restart rather than another login.
hasty pebble
OK what is the exact next step?
noble waspBOT
OK what is the exact next step?
Exact next step: force OpenClaw to select the fresh profile, then restart only NSSM.
Run these two commands:
openclaw config set auth.order.openai '["openai-codex:bsavino@outlook.com"]' --strict-json
openclaw config set auth.order.openai-codex '["openai-codex:bsavino@outlook.com"]' --strict-json
Then restart the NSSM service from NSSM/Services, not with openclaw gateway restart.
After it restarts, run this test:
openclaw agent --agent main --session-id diag-cli --message "hello" --timeout 60
If that still returns token_expired, paste:
openclaw config get auth.order --json
openclaw gateway status --deep --timeout 5000
should I get a later version of openclaw?
noble waspBOT
should I get a later version of openclaw?
Yes, I would. You’re on 2026.5.12, and I saw relevant fixes after that around Codex auth/profile repair, doctor repair for Codex runtime plugin state, app-server watchdogs, session reset/orphan cleanup, and gateway restart diagnostics.
But do it with NSSM in mind:
OpenClaw Gateway scheduled task first if NSSM is your real supervisor.openclaw update --no-restart
openclaw --version
openclaw gateway status --deep --timeout 5000
openclaw models auth list --provider openai-codex
This avoids the updater re-touching the scheduled task while still getting you the post-5.12 fixes.
hasty pebble
PS C:\windows\system32> openclaw config set auth.order.openai '["openai-codex:bsavino@outlook.com"]' --strict-json
🦞 OpenClaw 2026.5.12 (f066dd2) — The lobster in your shell. 🦞
Error: Could not parse "[openai-codex:bsavino@outlook.com]" as JSON for --strict-json. Unexpected token 'o', "[openai-cod"... is not valid JSON. Use valid JSON, for example openclaw config set gateway.port 18789 --strict-json. For plain strings, omit --strict-json.
PS C:\windows\system32>
noble waspBOT
PS C:\windows\system32> openclaw config set auth.order.openai '["openai-codex:bs...
PowerShell ate the inner JSON quotes. Use PowerShell-escaped quotes:
openclaw config set auth.order.openai "[`"openai-codex:bsavino@outlook.com`"]" --strict-json
openclaw config set auth.order.openai-codex "[`"openai-codex:bsavino@outlook.com`"]" --strict-json
Then verify:
openclaw config get auth.order --json
You should see the profile id inside quotes in the JSON output.
hasty pebble
PS C:\windows\system32> openclaw config set auth.order.openai "["openai-codex:bsavino@outlook.com"]" --strict-json
🦞 OpenClaw 2026.5.12 (f066dd2) — I read logs so you can keep pretending you don't have to.
Error: Could not parse "[openai-codex:bsavino@outlook.com]" as JSON for --strict-json. Unexpected token 'o', "[openai-cod"... is not valid JSON. Use valid JSON, for example openclaw config set gateway.port 18789 --strict-json. For plain strings, omit --strict-json.
PS C:\windows\system32>
noble waspBOT
PS C:\windows\system32> openclaw config set auth.order.openai "[`"openai-codex:b...
PowerShell is still stripping the embedded quotes before OpenClaw receives the argument. Use a variable so the quotes are passed as data:
$json = '["openai-codex:bsavino@outlook.com"]'
openclaw config set auth.order.openai $json --strict-json
openclaw config set auth.order.openai-codex $json --strict-json
openclaw config get auth.order --json
If that still strips them, use PowerShell stop-parsing:
openclaw --% config set auth.order.openai ["openai-codex:bsavino@outlook.com"] --strict-json
openclaw --% config set auth.order.openai-codex ["openai-codex:bsavino@outlook.com"] --strict-json
The verify output should contain:
noble waspBOT
PS C:\windows\system32> openclaw config set auth.order.openai "[`"openai-codex:b...
{
"openai": ["openai-codex:bsavino@outlook.com"],
"openai-codex": ["openai-codex:bsavino@outlook.com"]
}
give me one long string command, I cannot type in multiline inputs
noble waspBOT
give me one long string command, I cannot type in multiline inputs
Use this single PowerShell line:
$json='["openai-codex:bsavino@outlook.com"]'; openclaw config set auth.order.openai $json --strict-json; openclaw config set auth.order.openai-codex $json --strict-json; openclaw config get auth.order --json
PS C:\windows\system32> $json='["openai-codex:bsavino@outlook.com"]'; openclaw config set auth.order.openai $json --strict-json; openclaw config set auth.order.openai-codex $json --strict-json; openclaw config get auth.order --json
🦞 OpenClaw 2026.5.12 (f066dd2) — Deployed locally, trusted globally, debugged eternally.
Error: Could not parse "[openai-codex:bsavino@outlook.com]" as JSON for --strict-json. Unexpected token 'o', "[openai-cod"... is not valid JSON. Use valid JSON, for example openclaw config set gateway.port 18789 --strict-json. For plain strings, omit --strict-json.
🦞 OpenClaw 2026.5.12 (f066dd2) — I run on caffeine, JSON5, and the audacity of "it worked on my machine."
Error: Could not parse "[openai-codex:bsavino@outlook.com]" as JSON for --strict-json. Unexpected token 'o', "[openai-cod"... is not valid JSON. Use valid JSON, for example openclaw config set gateway.port 18789 --strict-json. For plain strings, omit --strict-json.
{
"openai-codex": [
"openai-codex:bsavino@outlook.com"
]
}
PS C:\windows\system32>
noble waspBOT
PS C:\windows\system32> $json='["openai-codex:bsavino@outlook.com"]'; openclaw c...
Got it. Use a temp patch file so PowerShell stops eating the JSON quotes:
$patch="$env:TEMP\openclaw-auth-order.json5"; Set-Content -Path $patch -Value '{ auth: { order: { openai: ["openai-codex:bsavino@outlook.com"], "openai-codex": ["openai-codex:bsavino@outlook.com"] } } }'; openclaw config patch --file $patch; openclaw config get auth.order --json
Your output shows auth.order.openai-codex is already set, but auth.order.openai failed. This patch sets both in one shot.
hasty pebble
that worked, now what?
PS C:\windows\system32> $patch="$env:TEMP\openclaw-auth-order.json5"; Set-Content -Path $patch -Value '{ auth: { order: { openai: ["openai-codex:bsavino@outlook.com"], "openai-codex": ["openai-codex:bsavino@outlook.com"] } } }'; openclaw config patch --file $patch; openclaw config get auth.order --json
🦞 OpenClaw 2026.5.12 (f066dd2) — Your AI assistant, now without the $3,499 headset.
Config overwrite: C:\Users\bobbo.openclaw\openclaw.json (sha256 d5b23fe9ac21895afb468bd70a979a0ac58dafc95039ab84a502319fd20d7770 -> 1c73bd2939c219518286a6223f3d127dae57f3a730b6b750c4f3611d2dc96590, backup=C:\Users\bobbo.openclaw\openclaw.json.bak)
Applied 2 config update(s). Restart the gateway to apply.
{
"openai-codex": [
"openai-codex:bsavino@outlook.com"
],
"openai": [
"openai-codex:bsavino@outlook.com"
]
}
PS C:\windows\system32>
noble waspBOT
that worked, now what?
PS C:\windows\system32> $patch="$env:TEMP\openclaw-auth-...
Now restart the actual gateway supervisor and test.
Since you’re using NSSM and the scheduled task was causing trouble:
openclaw gateway status --deep --timeout 5000
openclaw agent --agent main --session-id diag-cli --message "hello" --timeout 60
Expected result: no more token_expired.
If the CLI agent works, test TUI fresh:
noble waspBOT
that worked, now what?
PS C:\windows\system32> $patch="$env:TEMP\openclaw-auth-...
openclaw tui --url ws://127.0.0.1:18789 --session diag-fresh --history-limit 5
If token_expired still appears after the NSSM restart, the running gateway is not the process/config/auth store we think it is, and the next thing to paste is openclaw gateway status --deep --timeout 5000.
hasty pebble
gateway is still connecting then reconnecting at tui start
noble waspBOT
gateway is still connecting then reconnecting at tui start
That’s now a TUI/client-connect symptom, not proof the agent run is fixed yet.
Run the CLI agent test first, because it bypasses TUI:
openclaw agent --agent main --session-id diag-cli --message "hello" --timeout 60
Then run this with a tiny timeout/log window right after the TUI reconnect loop:
openclaw health --verbose
openclaw logs --limit 300 --max-bytes 1000000 --plain --local-time
What matters:
openclaw agent ... works, Codex/auth is fixed and we focus only on TUI connect/session state.
noble waspBOT
gateway is still connecting then reconnecting at tui start
openclaw agent ... still shows token_expired, NSSM did not reload the updated config/auth order.gateway closed (1008), pairing required, auth mismatch, or scope mismatch, that’s a TUI auth/device-token issue.closed (1000), try bypassing existing TUI state:openclaw tui --url ws://127.0.0.1:18789 --session brand-new-tui-test --history-limit 0
Paste the CLI agent result first; that will stop us from mixing TUI reconnect noise with the actual model/auth problem.
hasty pebble
still this.. command to delete scheduled task, then wipe openclaw install, and get latest version with codex fixes
026-05-16T14:05:09.214-04:00 error Embedded agent failed before reply: OAuth token refresh failed for openai-codex: OpenAI Codex token refresh failed (401): {
"error": {
"message": "Could not validate your token. Please try signing in again.",
"type": "invalid_request_error",
"param": null,
"code": "token_expired"
}
}. Please try again or re-authenticate. | OAuth token refresh failed for openai-codex: OpenAI Codex token refresh failed (401): {
"error": {
"message": "Could not validate your token. Please try signing in again.",
"type": "invalid_request_error",
"param": null,
"code": "token_expired"
noble waspBOT
still this.. command to delete scheduled task, then wipe openclaw install, and g...
I’d separate install wipe from state wipe. Don’t delete ~\.openclaw yet, because that contains config, auth, sessions, workspaces, etc. Move/backup only if needed.
Run this in an Administrator PowerShell:
schtasks /Delete /TN "OpenClaw Gateway" /F; npm uninstall -g openclaw; npm cache verify; npm install -g openclaw@latest; openclaw --version
Then restart your NSSM service manually.
If you want to also clear the managed plugin/package cache without wiping your config/auth:
Rename-Item "$env:USERPROFILE\.openclaw
pm" "$env:USERPROFILE\.openclaw
pm.bak-$(Get-Date -Format yyyyMMddHHmmss)" -ErrorAction SilentlyContinue; npm install -g openclaw@latest; openclaw doctor --fix
I would not wipe C:\Users\bobbo\.openclaw unless you’re okay losing local OpenClaw state. If you want a true clean state, rename it rather than delete it:
Rename-Item "$env:USERPROFILE\.openclaw" "$env:USERPROFILE\.openclaw.bak-$(Get-Date -Format yyyyMMddHHmmss)"
After reinstall + NSSM restart, check:
openclaw gateway status --deep --timeout 5000
openclaw models auth login --provider openai-codex
openclaw models auth list --provider openai-codex
And for future updates with NSSM, use:
noble waspBOT
still this.. command to delete scheduled task, then wipe openclaw install, and g...
openclaw update --no-restart
then restart NSSM yourself, so OpenClaw doesn’t resurrect the Scheduled Task path.
hasty pebble
one command at a time
noble waspBOT
one command at a time
Yep. First command, Administrator PowerShell:
schtasks /Delete /TN "OpenClaw Gateway" /F
Run that and paste the result.
hasty pebble
done
hasty pebble
done
noble waspBOT
done
Next command:
npm install -g openclaw@latest
Paste the result or the final version line if it succeeds.
hasty pebble
But I already have "latest", I want the next versions right?
noble waspBOT
But I already have "latest", I want the next versions right?
Correct. I checked npm: latest is still 2026.5.12. The newer build is on beta right now: 2026.5.16-beta.2.
Use this command instead:
npm install -g openclaw@beta
Then run:
openclaw --version
Paste the version it prints.
hasty pebble
done prints betta
noble waspBOT
done prints betta
Good. Next command:
openclaw doctor --fix
Let it finish, then paste the final summary/errors.
hasty pebble
Doctor changes ---------------------------------------------------------------------------+
| |
| Removed stale OAuth auth profile shadow openai-codex:bsavino@outlook.com from |
| ~.openclaw\agents\apibot\agent\auth-profiles.json; this agent now inherits main auth. |
| Removed stale OAuth auth profile shadow openai-codex:bsavino@outlook.com from |
| ~.openclaw\agents\cashclaw\agent\auth-profiles.json; this agent now inherits main auth. |
| Removed stale OAuth auth profile shadow openai-codex:bsavino@outlook.com from |
| ~.openclaw\agents\dbbot\agent\auth-profiles.json; this agent now inherits main auth. |
| Removed stale OAuth auth profile shadow openai-codex:bsavino@outlook.com from |
| ~.openclaw\agents\devopsbot\agent\auth-profiles.json; this agent now inherits main |
| auth. |
| Removed stale OAuth auth profile shadow openai-codex:bsavino@outlook.com from |
| ~.openclaw\agents\fintech\agent\auth-profiles.json; this agent now inherits main auth. |
| Removed stale OAuth auth profile shadow openai-codex:bsavino@outlook.com from |
| ~.openclaw\agents\flutterbot\agent\auth-profiles.json; this agent now inherits main |
| auth.
noble waspBOT
Doctor changes -----------------------------------------------------------------...
That’s a very good sign. Doctor found exactly the stale per-agent OAuth shadows we suspected.
Next command: restart your NSSM OpenClaw service manually.
After it restarts, run:
openclaw gateway status --deep --timeout 5000
Paste the status if it still shows anything weird; otherwise we’ll run the chat test next.
hasty pebble
Gateway ------------------------+
| |
| Gateway service not installed. |
| |
+----------------------------------+
|
o Install gateway service now?
| No
|
o Gateway --------------------------------------------------------------------+
| |
| Run openclaw gateway install when you want to install the gateway service. |
| |
+------------------------------------------------------------------------------+
|
— Doctor complete.
noble waspBOT
Gateway ------------------------+
| |
| Gatewa...
That’s expected after deleting the Scheduled Task. Since NSSM is your supervisor, do not install the OpenClaw gateway service here.
Next: restart the NSSM service manually, then run:
openclaw gateway status --deep --timeout 5000
If status says service not installed but Connectivity probe: ok and listener is on 127.0.0.1:18789, that’s fine for NSSM. We mainly want to confirm the gateway is the new beta process and there’s no Scheduled Task conflict.
hasty pebble
still get gateway connect failure, reconnect then works
noble waspBOT
still get gateway connect failure, reconnect then works
If it reconnects and then works, that first connect failure is probably startup timing or the old client seeing the gateway during restart. Let’s not chase that unless it blocks use.
Run the actual chat test now:
openclaw agent --agent main --session-id diag-cli --message "hello" --timeout 60
If that replies, then try TUI:
openclaw tui --url ws://127.0.0.1:18789 --session diag-fresh --history-limit 5
If the agent command still errors, paste that exact error.
hasty pebble
still getting auth error | OpenAI Codex token refresh failed (401): {
"error": {
"message": "Could not validate your token. Please try signing in again.",
"type": "invalid_request_error",
"param": null,
"code": "token_expired"
}
}
noble waspBOT
still getting auth error | OpenAI Codex token refresh failed (401): {
"error":...
At this point the stale-profile selection is probably fixed; this error means the selected Codex credential itself is still not accepted by OpenAI.
Next exact step: re-auth on the beta build using device-code, which avoids the browser callback path that was hanging earlier:
openclaw models auth --agent main login --provider openai-codex --device-code
Let it complete, then restart NSSM and test again.
If this command hangs after saying OAuth complete, Ctrl+C after it prints the Auth profile: line, then run:
openclaw models auth list --provider openai-codex
The non-probe list only confirms the profile exists; the real proof is the next agent run.
hasty pebble
PS C:\windows\system32> openclaw models auth --agent main login --provider
OpenClaw could not parse this command: option '--provider <id>' argument missing
Try: openclaw models auth --help
PS C:\windows\system32>
noble waspBOT
PS C:\windows\system32> openclaw models auth --agent main login --provider
OpenC...
You stopped at --provider; it needs the provider value after it.
Run this exact single line:
openclaw models auth --agent main login --provider openai-codex --device-code
PS C:\windows\system32> openclaw models auth --agent main login --provider openai-codex --device-code
OpenClaw does not recognize option "--device-code".
Try: openclaw models auth --help
PS C:\windows\system32>
noble waspBOT
PS C:\windows\system32> openclaw models auth --agent main login --provider opena...
Your installed CLI doesn’t have the --device-code shortcut exposed on that command path. Use the method form instead:
openclaw models auth --agent main login --provider openai-codex --method device-code
If that also says the method is unknown, run this one instead and use the normal browser flow:
openclaw models auth --agent main login --provider openai-codex
Also quick sanity check after:
openclaw --version
It should show the beta version, not 2026.5.12.
hasty pebble
done and no hang
Updated ~.openclaw\openclaw.json
Auth profile: openai-codex:bsavino@outlook.com (openai-codex/oauth)
Default model available: openai/gpt-5.5 (use --set-default to apply)
Tip: Codex-capable models can use native Codex web search. Enable it with openclaw configure --section web (recommended mode: cached). Docs: https://docs.openclaw.ai/tools/web
PS C:\windows\system32>
noble waspBOT
done and no hang
Updated ~\.openclaw\openclaw.json
Auth profile: openai-codex:b...
Great. Now restart the NSSM service manually so the gateway reloads that new auth.
After NSSM restart, run this one command:
openclaw agent --agent main --session-id diag-cli --message "hello" --timeout 60
Paste the result. If that works, TUI is next.
hasty pebble
PS C:\windows\system32> openclaw agent --agent main --session-id diag-cli --message "hello" --timeout 60
🦞 OpenClaw 2026.5.16-beta.2 (dba00cb) — I've read more man pages than any human should—so you don't have to.
|
o
GatewayClientRequestError: FailoverError: OAuth token refresh failed for openai-codex: OpenAI Codex token refresh failed (401): {
"error": {
"message": "Could not validate your token. Please try signing in again.",
"type": "invalid_request_error",
"para...
PS C:\windows\system32>
noble waspBOT
PS C:\windows\system32> openclaw agent --agent main --session-id diag-cli --mess...
Next exact command:
openclaw gateway status --deep --timeout 5000
We need to confirm the gateway process is also 2026.5.16-beta.2, not just the CLI. The agent command header only proves the CLI is beta; the request still goes through whatever gateway NSSM is running.
If status shows Gateway version is still 2026.5.12, NSSM is pointing at the old install or did not restart cleanly. If Gateway version is beta too, then the remaining problem is the OpenAI Codex OAuth credential itself, not the old version.
hasty pebble
PS C:\windows\system32> openclaw gateway status --deep --timeout 5000
🦞 OpenClaw 2026.5.16-beta.2 (dba00cb) — Greetings, Professor Falken
|
o
Service: Scheduled Task (missing)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-05-16.log
Command: C:\Program Files\nodejs\node.exe C:\Users\bobbo\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_GATEWAY_PORT=18789
Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json
Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.
CLI version: 2026.5.16-beta.2 (~\AppData\Roaming\npm\node_modules\openclaw\openclaw.mjs)
Gateway version: 2026.5.16-beta.2
Runtime: stopped (ERROR: The system cannot find the file specified.)
Connectivity probe: ok
Capability: admin-capable
Service unit not found.
Service not installed. Run: openclaw gateway install
File logs: C:\Users\bobbo\AppData\Local\Temp\openclaw\openclaw-2026-05-16.log
Listening: 127.0.0.1:18789
Other gateway-like services detected (best effort):
noble waspBOT
PS C:\windows\system32> openclaw gateway status --deep --timeout 5000
🦞 OpenCl...
Gateway is beta too, so the old-install theory is gone. The remaining failure is: the selected Codex OAuth credential refresh is rejected by OpenAI.
Next exact command:
openclaw models auth list --provider openai-codex
Paste that output again after the beta login. I want to confirm the expiry/profile timestamp changed after the no-hang login.
Then run this:
openclaw models status --probe-provider openai-codex --timeout 15000
No --probe flag, just --probe-provider. On beta it should give us a bounded provider/profile status rather than hanging forever.
hasty pebble
PS C:\windows\system32> openclaw models auth list --provider openai-codex
🦞 OpenClaw 2026.5.16-beta.2 (dba00cb)
I don't have opinions about tabs vs spaces. I have opinions about everything else.
Agent: main
Auth state file: ~.openclaw\agents\main\agent\auth-state.json
Provider: openai-codex
Profiles:
noble waspBOT
PS C:\windows\system32> openclaw models auth list --provider openai-codex
🦞 Op...
That confirms the beta login wrote a fresh profile at ~18:17 UTC.
Now run the bounded probe:
openclaw models status --probe-provider openai-codex --timeout 15000
Paste the output. If it says the same 401, then the stored OAuth profile is fresh locally but OpenAI is rejecting its refresh token, which likely means the account/session grant itself is bad or not valid for Codex.
hasty pebble
PS C:\windows\system32> openclaw models status --probe-provider openai-codex --timeout 15000
🦞 OpenClaw 2026.5.16-beta.2 (dba00cb) — Open source means you can see exactly how I judge your config.
Config : ~.openclaw\openclaw.json
Agent dir : ~.openclaw\agents\main\agent
Default : openai/gpt-5.5
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : opus -> anthropic/claude-opus-4-7
Configured models (3): anthropic/claude-opus-4-7, openai/gpt-5.5, anthropic/claude-haiku-4-5
Auth overview
Auth store : ~.openclaw\agents\main\agent\auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (3): anthropic (1), claude-cli (1), openai-codex (1)
OAuth/token status
noble waspBOT
PS C:\windows\system32> openclaw models status --probe-provider openai-codex --t...
Good. That probe says the Codex OAuth profile is valid now:
openai-codex:bsavino@outlook.com ... ok expires in 10d
Next exact step: restart the NSSM service one more time so the gateway drops any stale in-memory auth, then run a fresh session id:
openclaw agent --agent main --session-id diag-auth-ok --message "hello" --timeout 60
Use diag-auth-ok, not the earlier diag-cli.
If that still says token_expired, paste the first 30 lines around that error from:
noble waspBOT
PS C:\windows\system32> openclaw models status --probe-provider openai-codex --t...
openclaw logs --limit 500 --max-bytes 1000000 --plain --local-time
At that point the local auth store is proven OK, so the remaining issue would be gateway/runtime using stale auth despite the valid profile.
hasty pebble
PS C:\windows\system32> openclaw agent --agent main --session-id diag-auth-ok --message "hello" --timeout 60
🦞 OpenClaw 2026.5.16-beta.2 (dba00cb) — iMessage green bubble energy, but for everyone.
|
o
GatewayClientRequestError: FailoverError: OAuth token refresh failed for openai-codex: OpenAI Codex token refresh failed (401): {
"error": {
"message": "Could not validate your token. Please try signing in again.",
"type": "invalid_request_error",
"para...
PS C:\windows\system32>
noble waspBOT
PS C:\windows\system32> openclaw agent --agent main --session-id diag-auth-ok --...
The local auth probe is OK, but the gateway-run agent path still refreshes a bad token. That means the gateway process is not using the same fresh auth state the CLI just validated, or it has stale auth loaded in its runtime path.
Best isolation now: stop NSSM, then run the gateway in the foreground from the same PowerShell/account where models status showed the profile as OK.
First step: stop the NSSM OpenClaw service.
Then run this in PowerShell:
openclaw gateway --port 18789
Leave that window open. In a second PowerShell, run:
openclaw agent --agent main --session-id diag-foreground --message "hello" --timeout 60
If that works, NSSM is the problem: wrong environment, stale process, or different state/auth path. If it still fails, we have a real beta Codex auth/runtime bug with a clean repro: local models status --probe-provider openai-codex says OK, but gateway agent run gets token_expired.
noble waspBOT
can you open a defect?
I can’t open GitHub issues on your behalf, but I can give you a ready-to-paste defect.
Title:
Windows/NSSM Codex OAuth: models probe OK but gateway agent run uses expired openai-codex token
Body:
### Environment
- OS: Windows
- OpenClaw: 2026.5.16-beta.2 (dba00cb)
- Install: npm global
- Gateway supervisor: NSSM
- Old OpenClaw Scheduled Task existed and was deleted
- Model: openai/gpt-5.5
where do I post this?
noble waspBOT
can you open a defect?
- Codex profile: openai-codex:bsavino@outlook.com
### Symptoms
After upgrading from 2026.5.12, Codex agent runs fail with:
OAuth token refresh failed for openai-codex: OpenAI Codex token refresh failed (401)
code: token_expired
message: Could not validate your token. Please try signing in again.
But local model/auth probe reports the same profile as valid:
openclaw models status --probe-provider openai-codex --timeout 15000
...
noble waspBOT
can you open a defect?
openai-codex:bsavino@outlook.com ok expires in 10d
### What was tried
- Deleted stale Windows Scheduled Task: OpenClaw Gateway
- Reinstalled OpenClaw beta: 2026.5.16-beta.2
- Ran `openclaw doctor --fix`
- Doctor removed stale per-agent OAuth shadows from multiple agents
- Re-authenticated `openai-codex`
- Forced auth order:
```json
{
"auth": {
"order": {
"openai": ["openai-codex:bsavino@outlook.com"],
"openai-codex": ["openai-codex:bsavino@outlook.com"]}
}
}
### Current repro
```powershell
openclaw models auth list --provider openai-codex
openclaw models status --probe-provider openai-codex --timeout 15000
openclaw agent --agent main --session-id diag-auth-ok --message "hello" --timeout 60
Expected:
Agent run uses the valid probed Codex OAuth profile.
Actual:
Agent run fails with `token_expired`, despite probe showing the profile OK.
### Additional context
Earlier 2026.5.12 also had:
- managed Codex app-server binary not found
- Windows `codex.cmd` wrapper rejected: no executable/Node entrypoint could be resolved without shell execution
- Scheduled Task was reintroduced/used during update despite NSSM being the intended supervisor
File it here: https://github.com/openclaw/openclaw/issues
noble waspBOT
I'm done debugging this
Totally fair. This was too many stacked failures for one session.
Current best summary: your local Codex auth now probes OK on beta, but gateway agent runs still use/refresh an expired Codex token. That’s defect territory, not “keep poking at your config” territory.
I’d stop here, keep the beta install + deleted Scheduled Task state as-is, and file the issue with the template above when you have patience for it. If you need OpenClaw usable right now, switch the default agent to a non-Codex model/runtime temporarily and come back to Codex after a fix lands.