#Not working correctly

1 messages · Page 1 of 1 (latest)

coarse thistle
#

The cron job works but when I text my clanker on telegram it says {"detail":"The 'gpt-5.5' model is not supported when using Codex with a ChatGPT account."}

finite creekBOT
#

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

elfin zephyrBOT
#

Can you paste openclaw --version first? This smells like a model/runtime mismatch, not Telegram itself.

Likely: your Telegram session is using the native Codex runtime and asking Codex-with-ChatGPT for gpt-5.5, but that route/account doesn’t currently expose it. Cron can still work if the cron job has its own model override. OpenClaw keeps provider/model/runtime separate, and existing sessions can stay pinned until /new or /reset. (docs.openclaw.ai)

Try this if you meant “ChatGPT/Codex subscription auth through normal OpenClaw”:

openclaw models auth login --provider openai-codex
openclaw config set agents.defaults.model.primary openai-codex/gpt-5.5
openclaw config set agents.defaults.agentRuntime.id pi
openclaw gateway restart

Then send this in Telegram:

OpenClaw
Agent runtimes - OpenClaw
# 
/new

If you actually meant “native Codex app-server runtime,” don’t force gpt-5.5; pick a model your Codex account/client says is supported. OpenAI says GPT‑5.5 rollout to Codex can be gradual, and Codex model availability is separate from ChatGPT/API availability. (help.openai.com)

If that still fails, paste:

openclaw --version
openclaw models status
openclaw status --all
coarse thistle
#

how do I clean all the GPT auth accounts?

elfin zephyrBOT
#

Use the built-in auth logout, not manual JSON editing.

First check what’s stored:

openclaw --version
openclaw infer model auth status --json

Then clear OpenAI-family auth profiles:

openclaw infer model auth logout --provider openai-codex
openclaw infer model auth logout --provider openai
openclaw gateway restart
#

openai-codex = ChatGPT/Codex subscription OAuth.
openai = OpenAI API-key/provider auth profiles.

After that, re-login only the route you want, e.g. Codex subscription through normal OpenClaw/PI:

openclaw models auth login --provider openai-codex --device-code
openclaw config set agents.defaults.model.primary openai-codex/gpt-5.5
openclaw config set agents.defaults.agentRuntime.id pi
openclaw gateway restart

Then send /new in Telegram so the old stuck session doesn’t keep using the previous runtime/model.

Docs: https://docs.openclaw.ai/cli/infer and https://docs.openclaw.ai/providers/openai

coarse thistle
#

Okay, thats fixed, now it takes YEARS to react to a message in telegram, any tip I can give my clanker to optimize himself?

elfin zephyrBOT
#

Nice, one beast down 🎉

First: what does openclaw --version show?

For Telegram slowness, I’d separate “waiting before run starts” from “model is slow”:

openclaw status --all
openclaw logs --follow

Then send one Telegram message and watch where the delay is.

Quick knobs to try:

# 
# reduce artificial batching delay for Telegram
openclaw config set messages.inbound.byChannel.telegram 0
openclaw config set messages.queue.debounceMsByChannel.telegram 0
openclaw gateway restart

Then in Telegram:

/new
/status

/status should confirm the runtime/model. If it still says Codex runtime when you expected normal OpenClaw/PI, old session state may be sticking — /new usually clears that.

Other common “takes forever” causes:

#
  • Long old Telegram session context → use /new to test fresh.
  • A previous run is still active → /status, then maybe /queue interrupt.
  • Running on Bun / weird service env → openclaw doctor should complain; use Node/pnpm.
  • Model/provider latency → ask in #models for current fast setups; don’t guess from stale advice.

Docs: https://docs.openclaw.ai/concepts/messages and https://docs.openclaw.ai/help/faq

coarse thistle
#

14:35:32+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"pairing-required","handshake":"failed","durationMs":18,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"1e177a42-e43c-46f9-9f29-f666800dc826","host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":55180,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:55180->127.0.0.1:18789","deviceId":"f1583e1a6cb6da279e364b0e900eb1a1aebfc21d82b87ea16796d7644316381e","requestId":"5abdcfd8-5a8b-49a8-adbd-e64fac043480","reason":"scope-upgrade"} closed before connect conn=c53349a1-3442-4206-9a60-d35209c65588 peer=127.0.0.1:55180->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed
14:35:33+00:00 warn gateway {"subsystem":"gateway"} security audit: device access upgrade requested reason=scope-upgrade device=f1583e1a6cb6da279e364b0e900eb1a1aebfc21d82b87ea16796d7644316381e ip=unknown-ip auth=token roleFrom=operator roleTo=operator scopesFrom=operator.read scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write client=cli conn=064f57b8-5267-4fce-833b-cff35a566ad6
14:35:33+00:00 error gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: 5abdcfd8-5a8b-49a8-adbd-e64fac043480)
14:35:33+00:00 error gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: 5abdcfd8-5a8b-49a8-adbd-e64fac043480)

Im getting this error over and over and over in the openclaw logs --follow

elfin zephyrBOT
#

Yep — that log is a pending device scope upgrade, not a Telegram/model issue.

Your local CLI device is paired with only operator.read, but it’s now asking for broader operator scopes. Approve the current pending request:

openclaw --version
openclaw devices list
openclaw devices approve <requestId>

Use the current requestId from devices list — it may change if the client keeps retrying. In your pasted log it was:

openclaw devices approve 5abdcfd8-5a8b-49a8-adbd-e64fac043480

…but I’d still run openclaw devices list first.

#

Important nuance:

openclaw devices approve --latest

only previews the latest request; it doesn’t approve until you rerun with the exact ID.

After approving:

openclaw gateway restart
openclaw status

If it keeps looping after approval, run:

coarse thistle
#

How do I clean sessions?

Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /Users/enriquemurillo/.openclaw/agents/main/sessions/sessions.json (42 entries)

  • agent:main:telegram:direct:5024580021 (0m ago)
  • agent:main:cron:2bab87fd-26b6-40f6-9b87-5caf3092d8d4 (32m ago)
  • agent:main:cron:2bab87fd-26b6-40f6-9b87-5caf3092d8d4:run:e8741854-8dce-49f8-b09b-e29e4351bc4b (32m ago)
  • agent:main:main (44m ago)
  • agent:main:cron:2bab87fd-26b6-40f6-9b87-5caf3092d8d4:run:e3861fe7-29a8-421a-a8e4-ad250fd2e586 (62m ago)
elfin zephyrBOT
#

Depends what you mean by “clean”:

1) Just reset the Telegram chat context
Send this in Telegram:

/new

or

/reset

That’s usually enough after model/runtime/auth changes.

#

2) Clean old stored sessions safely

Preview first:

openclaw sessions cleanup --all-agents --dry-run

Then apply:

openclaw sessions cleanup --all-agents --enforce

With only 42 entries, default cleanup may not remove much because defaults are roughly “warn, prune after 30d, max 500 entries”.

3) Make cleanup more aggressive

#

Example: keep fewer entries / prune older sessions sooner:

openclaw config set session.maintenance.mode enforce
openclaw config set session.maintenance.pruneAfter 7d
openclaw config set session.maintenance.maxEntries 20
openclaw sessions cleanup --all-agents --enforce
openclaw gateway restart

4) Nuclear reset all session history
Only if you’re okay losing session history/transcripts:

openclaw gateway stop
mv ~/.openclaw/agents/main/sessions ~/.openclaw/agents/main/sessions.backup.$(date +%Y%m%d-%H%M%S)