upgraded to 5.12; having login issues

[wary tree]

I upgraded OpenClaw to 2026.5.12 and started seeing GPT-5.5 login/auth issues after running openclaw doctor --fix.

The key change is that doctor migrated model routes from:

openai-codex/gpt-5.5

to:

openai/gpt-5.5

and added:

agentRuntime.id = "codex"

for the migrated openai/gpt-5.5 entries.

Question:
In 2026.5.12, is this the intended config shape for GPT-5.5 via Codex OAuth?

model.primary = "openai/gpt-5.5"
models.openai/gpt-5.5.agentRuntime.id = "codex"

Or should GPT-5.5 via Codex OAuth still be declared as:

openai-codex/gpt-5.5

I am still having login/auth issues after the doctor fix and restart.
I’ll post the sanitized doctor context separately.

[obtuse mango]

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

[bleak rock]

I checked current docs/source. Short answer: yes, the doctor migration shape is intended for the native Codex runtime path.

For current config, use canonical OpenAI model refs:

agents: {
  defaults: {
    model: { primary: "openai/gpt-5.5" },
    models: {
      "openai/gpt-5.5": {
        agentRuntime: { id: "codex" }
      }
    }
  }
}

[bleak rock]

agentRuntime.id: "codex" is optional in normal auto routing, but it is useful because it makes the route fail closed if Codex is unavailable. New config should not use openai-codex/gpt-* model refs; doctor rewrites those to openai/gpt-* and moves the Codex intent onto provider/model-scoped agentRuntime.id: "codex".

Important distinction: openai-codex:* auth profiles can still exist and are valid. The model ref changes to openai/gpt-5.5; the Codex subscription auth is selected via the Codex runtime/auth profile plumbing. Current docs also recommend putting subscription-first order under auth.order.openai, for example:

auth: {
  order: {
    openai: ["openai-codex:[e-mail]", "openai:api-key-backup"]
  }
}

For the remaining auth issue, I’d check these in order:

1. Confirm exact version: openclaw --version
2. Re-login if needed: openclaw models auth login --provider openai-codex
3. Make sure the bundled Codex plugin is enabled, and if you use plugins.allow, include codex
4. Restart gateway, then use /new or /reset in the affected chat so stale session runtime pins do not keep the old route

[bleak rock]

5. Check /status; expected runtime is Runtime: OpenAI Codex
6. If it still fails, run/paste sanitized openclaw status --all or doctor output

Docs I checked:
https://docs.openclaw.ai/plugins/codex-harness
https://docs.openclaw.ai/gateway/doctor
https://docs.openclaw.ai/reference/wizard

[wary tree]

Sanitized doctor context:

After running:

openclaw doctor --fix

doctor reported:

Repaired Codex model routes:

• agents.defaults.model.primary:
  openai-codex/gpt-5.5 -> openai/gpt-5.5
• agents.defaults.imageModel.primary:
  openai-codex/gpt-5.5 -> openai/gpt-5.5
• agents.defaults.models.openai-codex/gpt-5.5:
  openai-codex/gpt-5.5 -> openai/gpt-5.5
• agents.list.<multiple-agents>.model.primary:
  openai-codex/gpt-5.5 -> openai/gpt-5.5

It also added this runtime mapping:

agents.defaults.models.openai/gpt-5.5.agentRuntime.id = "codex"
agents.list.<agent>.models.openai/gpt-5.5.agentRuntime.id = "codex"

Auth profile still appears to be Codex OAuth-shaped:

auth.profiles.openai-codex:<REDACTED_EMAIL>.provider = "openai-codex"
auth.profiles.openai-codex:<REDACTED_EMAIL>.mode = "oauth"

Doctor also said:

Installed missing configured plugin "codex" from @openclaw/codex.
codex agent runtime configured, enabled automatically.
Repaired Codex session routes: moved 81 sessions across 6 stores to openai/* while preserving auth-profile pins.
Config overwrite: ~/.openclaw/openclaw.json (... -> ..., backup=~/.openclaw/openclaw.json.bak, changedPaths=79)

Remaining non-core warnings:

• failed to remove legacy plugin dependency state due to EBUSY:
  /var/lib/openclaw/plugin-runtime-deps
• no command owner configured
• stale agent directory exists without matching agents.list entry
• orphan transcript files found
• browser executable path missing
• gateway bound to lan / 0.0.0.0

Main questions:

1. Is openai/gpt-5.5 + agentRuntime.id = "codex" the correct new route?
2. Should the auth profile remain under openai-codex:<email> with provider openai-codex?
3. Could doctor have migrated model/session routes but left auth state mismatched?
4. What command sequence should I use to re-auth or repair Codex OAuth state?
5. Should I keep the doctor-fixed config or temporarily revert to openai-codex/gpt-5.5?

[bleak rock]

Yep, that doctor output looks internally consistent.

Answers:

1. Yes: openai/gpt-5.5 + provider/model agentRuntime.id = "codex" is the correct repaired route.
2. Yes: the auth profile can remain openai-codex:<email> with provider = "openai-codex" and mode = "oauth". That is auth identity, not the model route.
3. Possible, but not from the route migration itself. The likely mismatch cases are stale/invalid OAuth tokens, auth stored for one agent but not another, stale session pins, or auth order still pointing somewhere surprising. Doctor explicitly says it preserved auth-profile pins, so I would treat the route migration as expected and validate auth separately.
4. I’d use this sequence:

openclaw --version
openclaw models status
openclaw models auth list --provider openai-codex
openclaw config get agents.defaults.model --json
openclaw config get models.providers.openai.agentRuntime --json
openclaw doctor --fix
openclaw config validate

[bleak rock]

If models auth list shows no usable Codex OAuth profile, or status/probe says refresh/auth failed:

openclaw models auth login --provider openai-codex
# if browser callback is awkward/headless:
openclaw models auth login --provider openai-codex --device-code
openclaw models status --probe --probe-provider openai-codex
openclaw gateway restart

For multi-agent setups, also check the affected agent stores, since auth is per agent:

openclaw models status --agent <agentId>
openclaw models auth list --agent <agentId> --provider openai-codex

[bleak rock]

Then in the affected Discord thread/chat, run /new or /reset, then /status and /codex status. Expected runtime is Runtime: OpenAI Codex.

5. Keep the doctor-fixed config. I would not revert to openai-codex/gpt-5.5; current docs call that legacy and doctor will repair it back to openai/gpt-5.5 anyway.

The EBUSY plugin-runtime-deps warning is probably not the auth cause. A gateway restart, or stopping the gateway before re-running doctor, should clear that cleanup later. The LAN bind warning is security-related, worth fixing separately, but not likely the Codex OAuth failure.

[wary tree]

After upgrading to OpenClaw 2026.5.12, doctor migrated my GPT-5.5 Codex route to the new shape:

model.primary = "openai/gpt-5.5"
models.openai/gpt-5.5.agentRuntime.id = "codex"

I refreshed openai-codex OAuth, recreated the gateway container, and the gateway now starts with the codex plugin loaded.

But Porygon Telegram slash commands like /new, /status, and /codex status are still extremely slow or stuck.

The key log during the delay is:

liveness warning: event_loop_delay
eventLoopDelayMaxMs=42345.7
eventLoopUtilization=0.866
phase=channels.whatsapp.start-account
active=agent:porygon:telegram:slash:<redacted>(processing,q=1,age=48s)
queued=agent:porygon:telegram:slash:<redacted>(processing,q=1,age=48s)

Question:
Can WhatsApp startup/reconnect block or starve unrelated Telegram slash-command handling like this? Should I temporarily disable WhatsApp to isolate Porygon/Codex, or is there a better config/runtime fix?

[bleak rock]

Yes. Channels share the same Gateway Node process/event loop, so a bad WhatsApp startup/reconnect path can absolutely starve unrelated Telegram slash handling. /new and /status should not be Codex-model-bound slow; if the log says event_loop_delay with phase=channels.whatsapp.start-account, I’d treat this as gateway/channel starvation first, not a GPT-5.5 route problem.

eventLoopDelayMaxMs=42345 means the event loop was blocked/delayed for ~42s. That is severe enough to make Telegram commands look stuck even if their own queue is tiny.

I’d isolate it this way:

openclaw --version
openclaw channels status --channel whatsapp --probe --json
openclaw channels status --channel telegram --probe --json
openclaw status --all

Then temporarily disable WhatsApp and restart the gateway. If you have one WhatsApp account, this is the simplest test:

[bleak rock]

openclaw config set channels.whatsapp.enabled false
openclaw config validate
openclaw gateway restart

If you have multiple WhatsApp accounts and only want to isolate one, set that account’s enabled field to false in ~/.openclaw/openclaw.json instead, then validate/restart.

After restart, test Telegram only:

/new
/status
/codex status

If Telegram becomes fast, keep the doctor-fixed Codex config and focus on WhatsApp. I would not revert to openai-codex/gpt-5.5; that just brings back legacy route state and will muddy the test.

[bleak rock]

Next WhatsApp-specific checks:

• Stop any local TUI/chat clients during the test; doctor has specific responsiveness guidance for event-loop degradation when TUI clients are also running.
• Check whether WhatsApp auth/session state is wedged. If you can afford relinking, openclaw channels logout --channel whatsapp --account <id> followed by WhatsApp login/relink is a cleaner test than repeatedly restarting a broken Baileys session.
• If /var/lib/openclaw/plugin-runtime-deps was EBUSY, fully stop the container/gateway before rerunning openclaw doctor --fix; don’t chase that first unless the plugin install keeps failing.

If disabling WhatsApp fixes Telegram, this is worth filing as a GitHub issue with sanitized openclaw --version, the liveness warning, channels status --probe, and whether disabling WhatsApp clears it: https://github.com/openclaw/openclaw/issues

Docs refs: https://docs.openclaw.ai/help/faq https://docs.openclaw.ai/cli/channels https://docs.openclaw.ai/channels/whatsapp

[wary tree]

Additional sanitized context:

Earlier after doctor --fix, the gateway log showed:

Error: Requested agent harness "codex" is not registered.

Doctor had installed/enabled the codex plugin, and the log said:

config change requires gateway restart (plugins.installs.codex)

After a clean gateway recreate, the gateway now starts with:

http server listening (... codex ...)

So the old “codex harness not registered” issue appears fixed.

Then /status showed:

Runtime: OpenAI Codex
Model: openai/gpt-5.5

But /codex status later showed:

Codex app-server: unavailable
OAuth token refresh failed
401 token_expired

I then re-ran:

openclaw models auth login --provider openai-codex

Auth refreshed successfully. Both main and porygon now show the refreshed openai-codex OAuth profile, expiring later than before.

After another clean gateway recreate, startup still shows:

startup model warmup timed out after 5000ms; continuing without waiting

Then when I send Porygon /new or /status over Telegram, the response is very slow or does not arrive promptly. During that delay, the log points to:

phase=channels.whatsapp.start-account
active=agent:porygon:telegram:slash:<redacted>
queued=agent:porygon:telegram:slash:<redacted>
event_loop_delay / event_loop_utilization warnings

So current suspicion is no longer config shape or missing OAuth. It looks like gateway event-loop starvation, possibly caused by WhatsApp startup/reconnect, is delaying Telegram slash-command handling and/or Codex app-server startup.

Questions:

1. Is this a known issue in 2026.5.12?
2. Is disabling WhatsApp the right isolation test?
3. Is there a setting to make channel startup/reconnect not block agent execution?
4. Should I also disable startup model warmup while testing?
5. What logs/commands would best confirm whether this is WhatsApp, Codex app-server startup, or general event-loop starvation?

[bleak rock]

That extra context makes the shape pretty clear: the Codex route/auth issue is probably resolved, and you’re now looking at gateway event-loop starvation.

Answers:

1. Yes, there are existing reports in this class. The closest match I found is channels.whatsapp.start-account blocking the event loop for ~30-40s and causing cross-channel latency/reconnect storms: https://github.com/openclaw/openclaw/issues/78165. There is also a broader cross-channel event-loop stall report: https://github.com/openclaw/openclaw/issues/75882.
2. Yes, disabling WhatsApp is the right isolation test. Your liveness phase points directly at channels.whatsapp.start-account, and Telegram slash commands share the same gateway event loop.
3. I don’t see a config knob that truly isolates channel startup/reconnect from agent execution. Channel startup is async at the call boundary, but if the WhatsApp plugin/Baileys path does a long synchronous chunk, it still blocks the Node event loop. Health-monitor/reconnect timing can change retry behavior, but it won’t fix a 40s synchronous block.
4. Yes, while testing, I’d disable startup model warmup too, but treat it as secondary. The source shows warmup is scheduled with a 5s timeout and channel startup continues without waiting, so it is unlikely to be the main blocker. Still, removing it makes the experiment cleaner.

Isolation sequence I’d run:

openclaw --version
openclaw status --all
openclaw channels status --channel whatsapp --probe --json
openclaw channels status --channel telegram --probe --json
openclaw models status --agent porygon

[bleak rock]

openclaw models auth list --agent porygon --provider openai-codex

Then set these for one clean test run:

openclaw config set channels.whatsapp.enabled false
openclaw config validate

And in the gateway container environment, add:

OPENCLAW_SKIP_STARTUP_MODEL_PREWARM=1

[bleak rock]

Recreate/restart the gateway, then immediately test Telegram:

/new
/status
/codex status

Best confirmation pattern:

• If Telegram is fast with WhatsApp disabled, this is WhatsApp startup/reconnect starving the shared gateway process.
• If Telegram is still slow with WhatsApp disabled and warmup skipped, look for liveness warnings without phase=channels.whatsapp.start-account; that points to general CPU/event-loop starvation or another startup phase.
• If /status is fast but /codex status is slow/unavailable, then isolate Codex app-server startup/auth separately.

Logs/evidence to keep:

openclaw logs --follow

[bleak rock]

openclaw health --json
openclaw channels status --channel all --probe --json
openclaw status --all

Capture the liveness warning lines with eventLoopDelayMaxMs, eventLoopUtilization, phase, recentPhases, and the active/queued work labels. For this specific symptom, I’d add your sanitized details to #78165 rather than reverting config. Keep openai/gpt-5.5 + Codex runtime; going back to openai-codex/gpt-5.5 will just reintroduce legacy routing noise.

[wary tree]

it is not workingl; i am plaaning to roll-back to the stable version of 2026.5.7; i created the backup using this command; docker exec openclaw-gateway openclaw backup create --verify; but i am not able to find out where the backup is stored or how to restore using this backup i created

[bleak rock]

That’s frustrating, but don’t delete/recreate anything until you’ve copied the backup off the container.

openclaw backup create --verify does not currently have a matching openclaw backup restore command. It creates a .tar.gz archive and prints the path as Backup archive: .... By default it writes to the current working directory inside the container unless you pass --output. In Docker that may be somewhere non-persistent, so first locate/copy it.

Try this:

docker exec openclaw-gateway sh -lc 'pwd; find /home/node /tmp /app -maxdepth 4 -type f -name "*openclaw-backup.tar.gz" 2>/dev/null'

When you find it, copy it to the host:

docker cp openclaw-gateway:/PATH/TO/2026-...-openclaw-backup.tar.gz ./

For future backups, write directly into the persistent OpenClaw mount:

[bleak rock]

docker exec openclaw-gateway sh -lc 'mkdir -p /home/node/.openclaw/backups && openclaw backup create --verify --output /home/node/.openclaw/backups --json'

Important: the backup you just created is a safety snapshot of the current 2026.5.12/migrated state, not a pre-upgrade restore point. For rolling back the runtime, I would first pin the Docker image to 2026.5.7 and keep the mounted state as-is:

export OPENCLAW_IMAGE=ghcr.io/openclaw/openclaw:2026.5.7
docker compose pull openclaw-gateway
docker compose up -d --force-recreate openclaw-gateway
docker compose logs -f openclaw-gateway

If 2026.5.7 cannot read the migrated config, then look for the doctor config backup inside the mounted state:

[bleak rock]

docker exec openclaw-gateway sh -lc 'ls -la /home/node/.openclaw/openclaw.json*'

You may have /home/node/.openclaw/openclaw.json.bak from doctor --fix. Restore that only if the downgraded gateway fails config validation, and keep a copy of both files first.

Manual archive restore, if you really need it, is: extract the tarball, inspect its manifest.json, then copy the payload/... paths back to the manifest’s recorded source paths while the gateway is stopped. I’d avoid doing that for a version rollback unless state is actually broken.

Docs: https://docs.openclaw.ai/cli/backup and Docker persistence notes: https://docs.openclaw.ai/install/docker#storage-and-persistence

[wary tree]

where is the tarball stored;l how do i extract it

[bleak rock]

The tarball is stored wherever openclaw backup create ran from. Since you ran it with:

docker exec openclaw-gateway openclaw backup create --verify

it was written inside the openclaw-gateway container, in that command’s current working directory. Find it first:

docker exec openclaw-gateway sh -lc 'pwd; find / -type f -name "*openclaw-backup.tar.gz" 2>/dev/null'

Then copy it from the container to your host:

docker cp openclaw-gateway:/PATH/TO/2026-...-openclaw-backup.tar.gz ./

[bleak rock]

To inspect/extract it on the host:

mkdir -p openclaw-backup-extracted
tar -tzf ./2026-...-openclaw-backup.tar.gz | head -50
tar -xzf ./2026-...-openclaw-backup.tar.gz -C ./openclaw-backup-extracted
find ./openclaw-backup-extracted -name manifest.json -print

The manifest.json tells you the original source paths and archive layout. Treat this archive as sensitive: it can contain config, OAuth/auth profiles, channel credentials, sessions, and workspace files.

For the next backup, choose an explicit persistent location so it’s easy to find:

docker exec openclaw-gateway sh -lc 'mkdir -p /home/node/.openclaw/backups && openclaw backup create --verify --output /home/node/.openclaw/backups'
docker exec openclaw-gateway sh -lc 'ls -lh /home/node/.openclaw/backups'

[wary tree]

We rolled back OpenClaw from 2026.5.12 to 2026.5.7. Core gateway now looks healthy: container is healthy, openclaw --version shows 2026.5.7, /status works, and logs show agent model: openai-codex/gpt-5.5 followed by ready.

Remaining issue appears WhatsApp-specific. Logs show repeated libsignal decrypt errors: Failed to decrypt message with any known session / Bad MAC, then event-loop pressure during phase=channels.whatsapp.start-account.

During rollback, robocopy also failed on a WhatsApp plugin dependency-tree item under .openclaw\npm\node_modules\@openclaw\whatsapp\node_modules\openclaw, likely symlink/junction/package-link related.

Question: before I move any WhatsApp credential/session state aside, what is the safest recovery path? Should I first reinstall/repair the WhatsApp plugin package tree, or should I back up and reset only .openclaw\credentials\whatsapp\default so it can relink/re-auth cleanly?

[bleak rock]

I’d do this in two phases: repair the plugin/package tree first, then relink WhatsApp only if decrypt errors continue.

Reason: the robocopy failure under .openclaw pm ode_modules\@openclaw\whatsapp ode_modules\openclaw sounds like managed plugin dependency/link drift. That is rebuildable install state. The WhatsApp credential store is your actual linked-device state, so touch that second.

Suggested safe order:

# 0) Make a fresh backup first
docker exec openclaw-gateway sh -lc 'mkdir -p /home/node/.openclaw/backups && openclaw backup create --verify --output /home/node/.openclaw/backups'

# 1) Check WhatsApp status
docker exec openclaw-gateway openclaw channels status --channel whatsapp --probe

[bleak rock]

# 2) Repair OpenClaw/plugin-managed package state on the 2026.5.7 runtime
docker exec openclaw-gateway openclaw doctor --fix

# 3) Restart/recreate gateway and recheck logs
docker restart openclaw-gateway
docker logs -f openclaw-gateway

If the plugin tree is still reported broken after doctor, then use the plugin repair/update path before touching creds:

docker exec openclaw-gateway openclaw plugins list --verbose
docker exec openclaw-gateway openclaw plugins update @openclaw/whatsapp
# or, if it was installed/tracked by id:
docker exec openclaw-gateway openclaw plugins update whatsapp

[bleak rock]

If WhatsApp still shows Failed to decrypt message with any known session / Bad MAC after the package tree is clean, then do the clean relink. Prefer the built-in logout/login flow over manually moving files first, because it stops the live listener and clears the right auth state:

docker exec openclaw-gateway openclaw channels logout --channel whatsapp --account default
docker exec openclaw-gateway openclaw channels login --channel whatsapp --account default --verbose

The credential path for that account is:

/home/node/.openclaw/credentials/whatsapp/default/creds.json

On the Windows host that maps to your mounted .openclaw\credentials\whatsapp\default directory. If you decide to move it aside manually, stop the gateway first and move the whole default folder to a timestamped backup name, not just one file.

So: package repair first, then WhatsApp relink/reset. Don’t robocopy node_modules plugin dependency trees as durable state; let OpenClaw/doctor/plugin update rebuild those.