protocol mismatch

[jaunty leaf]

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

[fervent pagoda]

That log is the Gateway rejecting an old WebSocket client, not a model/auth failure. webchat v1.0.0 / Control UI is speaking a protocol range the 5.12.26 gateway no longer accepts.

Try this loop:

openclaw --version
openclaw doctor

If doctor offers “Rebuild UI now? (Detected protocol mismatch requiring update)”, say yes. Then restart the gateway and open a fresh dashboard:

openclaw gateway restart
openclaw dashboard

Also close any old dashboard/webchat tabs, especially anything on localhost:3001; that looks like a stale dev webchat trying to connect to the new gateway.

If you installed/running from source and doctor can’t rebuild because UI sources are missing or stale, run from the repo checkout:

pnpm install
pnpm build
pnpm ui:build
openclaw gateway restart

Docs for the debug loop: https://docs.openclaw.ai/help/faq
Protocol notes: https://docs.openclaw.ai/gateway/protocol
Doctor notes: https://docs.openclaw.ai/gateway/doctor

If it still fails after that, paste openclaw --version and openclaw status --all so we can see whether the gateway itself is down or just the browser client is mismatched.

[karmic current]

Health check failed: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:54863
Source: local loopback
Config: C:\Users\User1.openclaw\openclaw.json
Bind: loopback
|
o Gateway ----------------------------------------------------------------+
| |
| Runtime: running (last run 267009, last run time 5/16/2026 6:51:20 PM) |
| |
+--------------------------------------------------------------------------+

[fervent pagoda]

That changes the picture: the supervisor thinks the gateway process is running, but the gateway is not answering the WS health probe within 10s. So now we need the startup log, not more dashboard troubleshooting.

Please run these and paste the relevant tail:

openclaw --version
openclaw gateway restart
openclaw gateway status
openclaw logs --follow

If logs --follow can’t connect, use the file-log fallback from the docs. On Windows, also check the latest OpenClaw log under your temp directory if the CLI prints the path.

A couple of likely causes from that output:

• ws://127.0.0.1:54863 is not the usual default port, so confirm you are opening the URL printed by openclaw dashboard, not an old browser/dev URL.
• Close stale Control UI/WebChat tabs, especially localhost:3001; those can keep hammering the gateway with old protocol handshakes, but they should not block startup by themselves.

[fervent pagoda]

• If restart still leaves “Runtime: running” + health timeout, the process may be wedged during boot. The log tail is the key thing to inspect next.

Docs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting

Good, that screenshot confirms the hammering is still the stale WebChat client:

client=webchat webchat v1.0.0
origin=http://localhost:3001
reason=protocol mismatch

That is not the current dashboard. Something on localhost:3001 is still open/running and repeatedly connecting to the gateway. Kill that first:

1. Close every browser tab for localhost:3001 and the old dashboard/webchat.
2. If you had a dev UI running, stop that terminal/process.
3. On Windows, you can find the process with:

netstat -ano | findstr :3001
taskkill /PID <pid> /F

Then restart and reopen only the dashboard URL from:

openclaw gateway restart
openclaw dashboard

For the “chat got no response” part, after the stale :3001 client is gone, try one message from the fresh dashboard and watch:

openclaw logs --follow

If it still does nothing, paste the new log lines after the chat attempt. The screenshot also shows a Telegram getMe fetch timeout, but that’s probably separate unless your OpenClaw is trying to deliver through Telegram.

[karmic current]

could this be why my chatbot isnt responding

[fervent pagoda]

Yes. That banner is enough to explain the no-response case if this chat is using the Codex/OpenAI Codex harness:

Managed Codex app-server binary was not found for @openai/codex

The gateway is up, but the selected chat backend can’t start its app-server, so the turn never gets a real agent response.

Try the repair path first:

openclaw --version
openclaw doctor
openclaw gateway restart

If this is a source checkout install, run this from the OpenClaw repo:

[fervent pagoda]

pnpm install
pnpm build
pnpm ui:build
openclaw gateway restart

If you are not intentionally using Codex, switch the chat/agent to a configured non-Codex backend in the UI and retry. If you are intentionally using Codex and it still shows this, reinstall/update OpenClaw so the managed Codex app-server package is present.

Relevant docs: https://docs.openclaw.ai/plugins/codex-harness and the standard debug loop: https://docs.openclaw.ai/help/faq

[karmic current]

20:52:00 Embedded agent failed before reply: 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 Codex binary.

getting this now

[fervent pagoda]

Yep, that is now the direct failure. Your dashboard is connecting, but the selected embedded agent is Codex and OpenClaw can’t find the Codex app-server binary it needs to run the turn.

Pick the path that matches your install:

If you installed from a source checkout:

cd <your-openclaw-repo>
pnpm install
pnpm build
pnpm ui:build
openclaw gateway restart

If you installed as a package / normal Windows install:

[fervent pagoda]

openclaw update
openclaw doctor
openclaw gateway restart

Then retry a dashboard chat.

Temporary workaround if you already have Codex installed separately: point OpenClaw at that binary. First check:

where codex
codex --version

Then in C:\Users\User1\.openclaw\openclaw.json, configure the Codex app-server command under the Codex plugin:

[fervent pagoda]

{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            command: "codex"
          }
        }
      }
    }
  }
}

[fervent pagoda]

Restart after changing config.

If openclaw update + doctor still leaves the managed binary missing on 5.12.26, that’s likely an install/package regression and worth filing with this exact error: https://github.com/openclaw/openclaw/issues

Docs: https://docs.openclaw.ai/plugins/codex-harness

[fervent pagoda]

That screenshot shows two separate things:

1. pnpm is not installed / not on PATH.
2. You’re in C:\Users\User1\.openclaw, which is the config/state folder, not the OpenClaw source checkout.

If this is the normal Windows/package install, don’t run pnpm install there. Use:

openclaw update
openclaw doctor
openclaw gateway restart

If you intentionally installed from source, first go to the actual repo folder, then enable/install pnpm:

[fervent pagoda]

corepack enable
corepack prepare pnpm@latest --activate
cd <your-openclaw-repo>
pnpm install
pnpm build
pnpm ui:build
openclaw gateway restart

If corepack is unavailable, install pnpm with npm:

npm install -g pnpm

Given your prompt path, I’d start with openclaw update + openclaw doctor, not the source checkout commands.

[karmic current]

openclaw update and then openclaw doctor didnt do anything to fix the issue

[fervent pagoda]

Got it. At this point we need the actual state, because there are two different failures in this thread:

1. protocol mismatch = stale/old UI client talking to the new gateway.
2. Managed Codex app-server binary was not found = Codex harness/plugin runtime issue.

Please paste text output, not a screenshot:

openclaw --version
openclaw status --all
openclaw gateway status --deep
openclaw doctor --repair

Then restart and open a fresh dashboard URL:

[fervent pagoda]

openclaw gateway restart
openclaw dashboard

Also close any old dashboard/webchat tabs, especially localhost:3001. That log line showed an old webchat v1.0.0 client, and doctor will not close a stale browser tab or dev server for you.

If the Codex binary error remains after doctor --repair, keep the temporary workaround you already have:

{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {

[fervent pagoda]

          appServer: {
            command: "codex"
          }
        }
      }
    }
  }
}

Docs I’m checking against:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/gateway/doctor
https://docs.openclaw.ai/plugins/codex-harness

[karmic current]

the protocol mismatch has nothing to do with the fact i cant chat with my claw, right? thats a backend server process im not concerned with right now.

right now im trying to get my claw communicating.

do i paste these all at once into powershell or one by one?:
openclaw --version
openclaw status --all
openclaw gateway status --deep
openclaw doctor --repair

[fervent pagoda]

Mostly right: the protocol mismatch is the browser/control UI connection to the gateway. If you’re chatting through that UI, it can absolutely prevent the UI from talking to your claw. But the later Managed Codex app-server binary was not found error is the more direct “agent can’t reply” problem.

Run them one by one in PowerShell. That makes it much easier to see which command fails, and openclaw doctor --repair may ask questions or take action.

Order:

openclaw --version

openclaw status --all

openclaw gateway status --deep

[fervent pagoda]

openclaw doctor --repair

Then paste the output from each. After doctor --repair, run:

openclaw gateway restart
openclaw dashboard

For the “can’t chat with my claw” issue, the key thing I’m looking for is whether the gateway is reachable and whether the Codex app-server/plugin dependency is still missing.

This output is useful: your gateway is running and reachable, and Telegram itself looks OK. So yeah, I’d stop chasing protocol mismatch for the moment unless you’re specifically using the browser dashboard to chat.

For “my claw receives/sends no reply”, the next thing is to catch the agent failure when you send a message. Run this in PowerShell:

openclaw logs --follow

Leave that window open, then send your claw a Telegram message. Paste the new log lines that appear right after that.

Also please run these separately and paste their output:

openclaw doctor --repair

openclaw models status

Why: status --all says transport is healthy, but it doesn’t prove the selected agent model/harness can start. The earlier Managed Codex app-server binary was not found points exactly at that layer.

[fervent pagoda]

Doctor looks clean for the “can my claw reply?” path. The commands.ownerAllowFrom warning is about privileged commands like /config and approvals; it should not block normal Telegram chat.

The state warning means one old main session transcript is missing, so that conversation may reset. That can confuse continuity, but it still shouldn’t stop new replies.

Next useful check is the agent/model layer. Please run:

openclaw models status

And separately:

openclaw logs --follow

While logs --follow is running, send your claw a Telegram message, then paste only the new lines that appear after the message. That will tell us whether Telegram receives it, whether it routes to main/Piper, and whether the agent crashes on model/Codex startup.

[karmic current]

PS C:\WINDOWS\system32> openclaw models status

🦞 OpenClaw 2026.5.12 (f066dd2) — I've survived more breaking changes than your last three relationships.

Config : ~.openclaw\openclaw.json
Agent dir : ~.openclaw\agents\main\agent
Default : openai/gpt-5.5
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : sonnet -> anthropic/claude-sonnet-4-6, GPT -> openai/gpt-5.4
Configured models (4): anthropic/claude-sonnet-4-6, openai/gpt-5.4, 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 (1): openai-codex (1)

• anthropic effective=profiles:~.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | anthropic:default=
• openai effective=profiles:~.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openai:default=
• openai-codex effective=profiles:~.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:[e-mail]=OAuth ([e-mail])

OAuth/token status

• openai-codex usage: 5h 100% left ⏱4h 59m · Week 98% left ⏱6d 16h
  • openai-codex:[e-mail] ([e-mail]) ok expires in 10d

[fervent pagoda]

This points at the likely problem: your default is openai/gpt-5.5, you have no fallbacks, and the earlier error says the Codex app-server binary needed for that path is missing. So the transport is healthy, but the agent runtime can’t start a reply.

Fastest test: switch to one of your already-configured non-Codex paths, then restart/start a fresh chat:

openclaw models set GPT
openclaw gateway restart

Then send the claw a new Telegram message. If that works, the issue is specifically the openai/gpt-5.5 / Codex app-server harness path, not Telegram or gateway communication.

You can also try this from Telegram if commands are being received:

/model GPT

[fervent pagoda]

If it still fails after switching, run openclaw logs --follow, send one Telegram message, and paste the fresh log lines after that message.

[karmic current]

but i want to use gpt 5.5 and dont i have to do that through codex? i just updated from 4.22 and it was like that then

[fervent pagoda]

Yes, you’re right that GPT-5.5 needs the Codex/ChatGPT subscription auth path right now. The important bit is that 5.x has two different Codex-ish routes:

• openai-codex/gpt-5.5 = Codex OAuth through the normal OpenClaw/PI runner. This is probably closest to what you had working before.
• openai/gpt-5.5 with Codex harness = native Codex app-server. That is the path throwing Managed Codex app-server binary was not found.

Your models status shows the OAuth profile is OK under openai-codex, but your default is currently openai/gpt-5.5. I’d switch the default to the OAuth route:

openclaw models set openai-codex/gpt-5.5
openclaw gateway restart

Then send your claw a fresh Telegram message.

If you specifically want the native app-server route instead, then we need to fix the local Codex app-server binary/PATH issue. But for “get Piper communicating on GPT-5.5 again”, openai-codex/gpt-5.5 is the cleaner next move.

Docs: https://docs.openclaw.ai/plugins/codex-harness and https://docs.openclaw.ai/cli/models

[karmic current]

whats the difference between the two routes?

[fervent pagoda]

Short version:

openai-codex/gpt-5.5 uses your Codex OAuth/subscription as a model provider inside OpenClaw’s normal embedded agent runner. OpenClaw still runs the session/runtime machinery, and the provider call goes through the OpenAI Codex OAuth integration. Fewer moving parts, closer to older behavior.

openai/gpt-5.5 + embeddedHarness.runtime: "codex" hands the actual agent turn to the native Codex app-server. That means Codex owns more of the low-level session execution, but OpenClaw still owns Telegram, tools, transcripts, approvals, etc. This route needs a working local Codex app-server binary. Your error says that binary was not found.

So for your situation:

• Want GPT-5.5 working again quickly: use openai-codex/gpt-5.5.
• Want the newer native Codex harness behavior: use openai/gpt-5.5, but first fix the missing app-server binary/PATH issue.

Docs phrase it as: openai-codex/* for Codex OAuth through PI, openai/* for direct OpenAI API or forced native Codex app-server harness.
https://docs.openclaw.ai/plugins/codex-harness

[karmic current]

i switched to openai-codex/gpt-5.5, restarted the gateway, even did /new - no response from claw just "..."

[fervent pagoda]

Okay, then we’re past the easy model-default fix. ... usually means the inbound message was accepted and the agent turn started, but the turn is hanging or failing before final output.

Two things to check now:

1. Make sure you changed the model for the same agent/account you’re messaging. You have multiple Telegram accounts/agents. If you’re messaging Cody/Chloe/etc, changing main may not affect that agent.

Run this for the claw you’re actually messaging, replacing cody if needed:

openclaw models status --agent cody

For Piper/main:

openclaw models status --agent main

[fervent pagoda]

2. Capture the actual failure/hang:

openclaw logs --follow

Leave it open, send the Telegram message that produces ..., wait ~30 seconds, then paste the new log lines from that window.

Also paste the output of:

openclaw sessions --store "C:\Users\User1\.openclaw\agents\main\sessions\sessions.json"

If the target is not Piper/main, use that agent’s sessions path from status --all instead. I’m looking for whether the route is still pinned to a stale/native Codex session despite /new, or whether a non-main agent is still on the broken openai/gpt-5.5 harness path.

[karmic current]

im doing this all in the webchat dashboard

[fervent pagoda]

Ah, then yes: the protocol mismatch is directly relevant. If you’re chatting through the webchat/dashboard, that browser client has to speak the same gateway protocol. The ... can be the UI getting stuck because the dashboard/webchat bundle is stale or you’re on an old dev tab.

Do this in order:

openclaw dashboard

Use the URL it prints/opens. Close every old OpenClaw tab first, especially anything on localhost:3001. Don’t reuse a bookmarked old dashboard URL.

Then hard refresh the new dashboard tab:

Ctrl+Shift+R

If it still shows ..., run:

[fervent pagoda]

openclaw logs --follow

Send one message in the dashboard, wait ~30 seconds, and paste the fresh log lines. Now that I know this is dashboard chat, the live logs are the fastest way to tell whether the browser protocol is still mismatched or the agent turn is starting and hanging.

[fervent pagoda]

These logs confirm both problems:

1. Your browser is still running the old dev webchat from http://localhost:3001 and the gateway rejects it: expected protocol 4, client sends protocol 3. Close/stop that tab/dev server and use the URL from openclaw dashboard instead.

2. More importantly for the ...: the agent is still selecting the native Codex harness and failing because the managed app-server binary is missing:

harnessId="codex" provider="openai-codex" modelId="gpt-5.5"
Managed Codex app-server binary was not found

To force the normal embedded runner while keeping openai-codex/gpt-5.5, run:

openclaw config set agents.defaults.embeddedHarness '{"runtime":"pi","fallback":"pi"}' --strict-json
openclaw gateway restart

[fervent pagoda]

Then open a fresh dashboard with:

openclaw dashboard

Close old localhost:3001 tabs, hard refresh the new dashboard, then /new and test again.

If it still fails after that, paste:

openclaw config get agents.defaults.embeddedHarness
openclaw logs --follow

The key is: right now your config/runtime is still going through native Codex app-server, not the PI/OpenClaw runner path.

[karmic current]

Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows

PS C:\WINDOWS\system32> openclaw config set agents.defaults.embeddedHarness '{"runtime":"pi","fallback":"pi"}' --strict-json

openclaw gateway restart

🦞 OpenClaw 2026.5.12 (f066dd2) — Half butler, half debugger, full crustacean.

Error: Could not parse "{runtime:pi,fallback:pi}" as JSON for --strict-json. Expected property name or '}' in JSON at position 1 (line 1 column 2). Use valid JSON, for example openclaw config set gateway.port 18789 --strict-json. For plain strings, omit --strict-json.

[fervent pagoda]

PowerShell ate the JSON quotes. Use nested config writes instead; no JSON quoting needed.

Run these one by one:

openclaw config set agents.defaults.embeddedHarness.runtime pi

openclaw config set agents.defaults.embeddedHarness.fallback pi

openclaw gateway restart

Then verify:

[fervent pagoda]

openclaw config get agents.defaults.embeddedHarness

You want it to show runtime/fallback as pi. After that, open a fresh dashboard with openclaw dashboard, close the old localhost:3001 tab, /new, and test again.

[karmic current]

Updated agents.defaults.embeddedHarness.runtime. Restart the gateway to apply.
PS C:\WINDOWS\system32> openclaw config set agents.defaults.embeddedHarness.fallback pi

🦞 OpenClaw 2026.5.12 (f066dd2) — I've survived more breaking changes than your last three relationships.

Error: Config validation failed: agents.defaults.embeddedHarness: Unrecognized key: "fallback"
PS C:\WINDOWS\system32>

[fervent pagoda]

Yep, that one is on me: your installed build accepts runtime but not fallback there. The first command succeeded, and that’s the important part.

Now just run:

openclaw gateway restart

Then verify:

openclaw config get agents.defaults.embeddedHarness

You want to see runtime: pi or equivalent. Then open a clean dashboard:

[fervent pagoda]

openclaw dashboard

Close the old localhost:3001 tab, hard refresh the dashboard, /new, and test again.

If it still errors, paste the fresh log lines. I expect the next logs should no longer say harnessId="codex"; if they still do, there’s another override, probably per-agent or an environment variable like OPENCLAW_AGENT_RUNTIME=codex.

[karmic current]

where and when do i put this? power shell? after the restart?:

Then verify:

openclaw config get agents.defaults.embeddedHarness

You want to see runtime: pi or equivalent. Then open a clean dashboard:

[fervent pagoda]

Yes, all in PowerShell. Do it in this exact order, one command at a time:

openclaw gateway restart

Wait for that to finish. Then verify the setting:

openclaw config get agents.defaults.embeddedHarness

If it shows runtime as pi, continue:

openclaw dashboard

[fervent pagoda]

That should open/print the correct dashboard URL. Use that one, close the old localhost:3001 tab, hard refresh the new dashboard with Ctrl+Shift+R, then type /new in the dashboard chat and test a message.

[karmic current]

Restarted Scheduled Task: OpenClaw Gateway
PS C:\WINDOWS\system32> openclaw config get agents.defaults.embeddedHarness

🦞 OpenClaw 2026.5.12 (f066dd2) — I've seen your commit messages. We'll work on that together.

{
"runtime": "pi"
}
PS C:\WINDOWS\system32> openclaw dashboard

🦞 OpenClaw 2026.5.12 (f066dd2) — Less clicking, more shipping, fewer "where did that file go" moments.

Dashboard URL: http://127.0.0.1:54863/
Token auto-auth included in browser/clipboard URL.
Copied to clipboard.
Opened in your browser. Keep that tab to control OpenClaw.
PS C:\WINDOWS\system32>

[fervent pagoda]

Good, that part is now correct: runtime: pi means it should stop using the native Codex app-server harness.

Now in the browser:

1. Close any old localhost:3001 / old OpenClaw dashboard tabs.
2. In the new http://127.0.0.1:54863/ tab, hard refresh with Ctrl+Shift+R.
3. In webchat, run:

/new

4. Send a normal test message.

If it still hangs at ..., run this in PowerShell while reproducing it:

[fervent pagoda]

openclaw logs --follow

The log should no longer say harnessId="codex". If it does, we know there’s still another override somewhere.

[karmic current]

21:57:12 [agents/harness] Codex agent harness failed; not falling back to embedded PI backend
21:57:12 [diagnostic] lane task error: lane=main durationMs=5376 error="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 Codex binary."
21:57:12 [diagnostic] lane task error: lane=session:agent:main:main durationMs=5383 error="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 Codex binary."
21:57:12 Embedded agent failed before reply: 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 Codex binary.

[fervent pagoda]

Since config get shows runtime: pi but the logs still select Codex, something else is overriding it. The two likely causes are: a per-agent override, an env var, or the existing webchat session is pinned to agentHarnessId: codex.

Run these in PowerShell and paste the output:

openclaw config get agents.list

Get-ChildItem Env:OPENCLAW_AGENT_RUNTIME,Env:OPENCLAW_AGENT_HARNESS_FALLBACK -ErrorAction SilentlyContinue

Select-String -Path "$env:USERPROFILE\.openclaw\agents\main\sessions\sessions.json" -Pattern 'agentHarnessId|agent:main:main|openai-codex|gpt-5.5' -Context 3,3

What I’m looking for: