Setting up email API, locked out. | Friends of the Crustacean 🦞🤝 | Page 1

cunning knoll Apr 21, 2026, 12:31 AM

#

My agent was setting up gmail, The agent had me set things up through google cloud, with an oauth client. I got the json information it needed, then it wrote what it needed. Aget replied:

What I set up:
Gmail OAuth venv at:
/home/michael/.openclaw/workspace/.venvs/gmail-oauth
Gmail helper script at:
/home/michael/.openclaw/workspace/tools/gmail_oauth.py

I was directed to a link

What should happen:

Ideally it opens a browser-based Google sign-in flow
If browser launch fails, it should fall back to a console flow

When I went to the link, I got an error 400: redirect_uri_mismatch.
My agent then locked up in thinking. I restarted, but when I tried to launch, I got the message:
nvalid config at /home/michael/.openclaw/openclaw.json:\n- skills.entries.agentmail: Unrecognized key: "AGENTMAIL_API_KEY"

🦞 OpenClaw 2026.4.15 (041266a)
Self-hosted, self-updating, self-aware (just kidding... unless?).

Config invalid
File: ~/.openclaw/openclaw.json
Problem:

skills.entries.agentmail: Unrecognized key: "AGENTMAIL_API_KEY"

Run: openclaw doctor --fix
I ran doctor with the end result:
Restarted systemd service: openclaw-gateway.service
Config overwrite: /home/michael/.openclaw/openclaw.json (sha256 ef9e290dc6274554e70950b8529ee8621f9733f2b8711d5be7cd2d9e8ef724df -> 0d874fd67adaabb71a98da8f940584c2e359ebbb6b3bcbd5b38b90aeda1c84de, backup=/home/michael/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Backup: ~/.openclaw/openclaw.json.bak
│
└ Doctor complete.
restarted the dashboard, but my agent does not reply.

little shoalBOT Apr 21, 2026, 12:31 AM

#

twilit pollenBOT Apr 21, 2026, 12:31 AM

#

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

little shoalBOT Apr 21, 2026, 12:31 AM

#

ruby spruceBOT Apr 21, 2026, 12:34 AM

#

You’ve probably got 2 separate problems here.

redirect_uri_mismatch
Google is rejecting the redirect URI the helper script sent.
That usually means one of these:
- the OAuth client was created as the wrong type, often Web application instead of Desktop app
- or the Google Cloud client does not have the exact redirect URI the script used, including port, path, and trailing slash
So, check the failing auth URL and look at its redirect_uri= value. That exact URI must match what’s in Google Cloud.
Invalid OpenClaw config
This part is definitely wrong:
```
skills.entries.agentmail.AGENTMAIL_API_KEY
```

#

Under skills.entries.<skill>, valid fields are things like enabled, env, apiKey, and config.
So if you actually need that AgentMail key, it should be shaped like:

{
  skills: {
    entries: {
      agentmail: {
        enabled: true,
        env: {
          AGENTMAIL_API_KEY: "your-key-here"
        }
      }
    }
  }
}

#

Or just remove the agentmail entry entirely if you are not using it.

What I’d do next

Fix/remove the bad agentmail config
Restart gateway
```
openclaw gateway restart
```

Run:

openclaw status
openclaw models status
openclaw logs --follow

In the dashboard, start a fresh session with:

#

   /new

A session that was already stuck mid-think during a config failure often does not recover cleanly.

Docs:

If you paste:

the exact redirect_uri value from the failing Google URL
and the output of openclaw status / openclaw models status

…I can tell you the next fix pretty precisely.

cunning knoll Apr 21, 2026, 12:44 AM

#

There was an issue with how the oauth client was created. I now have the correct type.

ruby spruceBOT Apr 21, 2026, 12:44 AM

#

Nice, that was very likely the root cause for the redirect_uri_mismatch.

At this point I’d do this, in order:

Do not restore ~/.openclaw/openclaw.json.bak
That backup likely still contains the bad agentmail field.
Restart the gateway once more
```
openclaw gateway restart
```
Start a fresh session in the dashboard
```
/new
```

#

Re-run the Gmail auth step
Since the old session wedged, I would not try to continue it. Start fresh and have the agent rerun the Gmail OAuth helper.

If it still goes silent after that, run:

openclaw status
openclaw models status
openclaw logs --follow

and paste the output here. Then we can tell whether it’s still the Gmail flow, or the agent session itself that’s stuck.

If you want, I can help you sanity-check the next Gmail step before you run it.

cunning knoll Apr 21, 2026, 12:59 AM

#

OpenClaw status

Overview
│
de 22.22.2 │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ serve · ainchor.tailf5ebd7.ts.net · https://ainchor.tailf5ebd7.ts.net │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.15 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 25ms · auth │
│ │ token · AInchor (192.168.1.5) app 2026.4.15 linux 6.17.0-20-generic │
│ Gateway self │ AInchor (192.168.1.5) app 2026.4.15 linux 6.17.0-20-generic │
│ Gateway service │ systemd installed · enabled · running (pid 6746, state active) │
│ Node service │ systemd not installed │
│ Agents │ 1 · no bootstrap files · sessions 1 · default main active 5m ago │
│ Memory │ 0 files · 0 chunks · dirty · sources memory · plugin memory-core · │
│ │ vector unknown · fts ready · cache on (0) │
│ Plugin compatibility │ none │
│ Probes │ skipped (use --deep) │
│ Events │ none │
│ Tasks │ none │
│ Heartbeat │ 30m (main) │
│ Sessions │ 1 active · default gpt-5.4 (200k ctx) · ~/.openclaw/agents/main/sessions/ │
│ │ sessions.json

ruby spruceBOT Apr 21, 2026, 1:00 AM

#

This status actually looks pretty healthy.

The important bits are:

Gateway reachable
systemd service running
agent active
1 active session

So this no longer looks like a broken gateway/config problem. It looks more like one of these:

the existing session is wedged
model auth/provider is failing when the agent tries to answer

Next 2 checks

Run:

#

openclaw models status
openclaw logs --follow

Then, in the dashboard, do not reuse the stuck conversation. Start a fresh one with:

/new

or open a brand new chat and send a simple test like hi.

Why I think it’s the session

Your status still shows 1 active session, which makes me think the old stuck one is still the only live session.

If you paste openclaw models status next, I can narrow it down fast.

cunning knoll Apr 21, 2026, 1:00 AM

#

michael@AInchor:~$ openclaw models status

🦞 OpenClaw 2026.4.15 (041266a)
Type the command with confidence—nature will provide the stack trace if needed.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.4
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): openai-codex/gpt-5.4

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): openai-codex (1)

ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json
openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:gravity66726@yahoo.com=OAuth (gravity66726@yahoo.com)

OAuth/token status

openai-codex usage: 168h 0% left ⏱6d 11h
- openai-codex:gravity66726@yahoo.com (gravity66726@yahoo.com) ok expires in 9d

ruby spruceBOT Apr 21, 2026, 1:01 AM

#

Ah, I think we found it.

Your auth is valid, but your provider usage is exhausted.

This line is the giveaway:

openai-codex usage: 168h 0% left ⏱6d 11h

So:

the login/token is still ok
but that provider currently has 0% usage left
which explains why the gateway is up, but the agent still doesn’t answer

So this is not the Gmail OAuth problem anymore. That part was separate.

#

What to do next

You have 2 real options:

Switch to another provider/model with available usage
Wait for that usage window to reset

After switching, start a fresh session:

/new

and then rerun the Gmail setup step.

One more confirmation check

If you want to verify it live, run:

#

openclaw logs --follow

Then send a message in the dashboard. I’d expect a quota/rate-limit style error there.

Docs:

If you want, paste the log output after one test message and I can confirm it.

cunning knoll Apr 21, 2026, 1:05 AM

#

too much text, should I post in segments, or can I upload the log file?

#

00:01:02+00:00 error Problem:
00:01:02+00:00 error - skills.entries.agentmail: Unrecognized key: "AGENTMAIL_API_KEY"
00:01:02+00:00 error {"0":"","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"openclaw","date":"2026-04-21T00:01:02.191Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///home/michael/.npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js:155:68","fileName":"subsystem-Cgmckbux.js","fileNameWithLine":"subsystem-Cgmckbux.js:155","fileColumn":"68","fileLine":"155","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js:155","method":"console.error"}},"time":"2026-04-20T20:01:02.191-04:00"}
00:01:02+00:00 error Run: openclaw doctor --fix
00:01:08+00:00 error Config invalid
00:01:08+00:00 error File: ~/.openclaw/openclaw.json
00:01:08+00:00 error Problem:
00:01:08+00:00 error - skills.entries.agentmail: Unrecognized key: "AGENTMAIL_API_KEY"
00:01:08+00:00 error {"0":"","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"openclaw","date":"2026-04-21T00:01:08.030Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///home/michael/.npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js:155:68","fileName":"subsystem-Cgmckbux.js","fileNameWithLine":"subsystem-Cgmckbux.js:155","fileColumn":"68","fileLine":"155","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js:155","method":"console.error"}},"time":"2026-04-20T20:01:08.030-04:00"}
00:01:08+00:00 error Run: openclaw doctor --fix
00:01:13+00:00 error Config invalid
00:01:13+00:00 error File: ~/.openclaw/openclaw.json
00:01:13+00:00 error Problem:
00:01:13+00:00 error - skills.entries.agentmail: Unrecognized key: "AGENTMAIL_API_KEY"

#

00:01:13+00:00 error {"0":"","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"openclaw","date":"2026-04-21T00:01:13.766Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///home/michael/.npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js:155:68","fileName":"subsystem-Cgmckbux.js","fileNameWithLine":"subsystem-Cgmckbux.js:155","fileColumn":"68","fileLine":"155","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js:155","method":"console.error"}},"time":"2026-04-20T20:01:13.766-04:00"}
00:01:13+00:00 error Run: openclaw doctor --fix
00:01:19+00:00 error Config invalid
00:01:19+00:00 error File: ~/.openclaw/openclaw.json
00:01:19+00:00 error Problem:
00:01:19+00:00 error - skills.entries.agentmail: Unrecognized key: "AGENTMAIL_API_KEY"
00:01:19+00:00 error {"0":"","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"openclaw","date":"2026-04-21T00:01:19.523Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///home/michael/.npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js:155:68","fileName":"subsystem-Cgmckbux.js","fileNameWithLine":"subsystem-Cgmckbux.js:155","fileColumn":"68","fileLine":"155","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js:155","method":"console.error"}},"time":"2026-04-20T20:01:19.523-04:00"}
00:01:19+00:00 error Run: openclaw doctor --fix
00:01:24+00:00 error Config invalid
00:01:24+00:00 error File: ~/.openclaw/openclaw.json
00:01:24+00:00 error Problem:

ruby spruceBOT Apr 21, 2026, 1:10 AM

#

This log snippet is helpful, but it’s showing the old config failure, not the current one.

Why I say that:

openclaw status works now
openclaw models status works now

So the config is currently loading.

The bigger current signal is still this from models status:

usage: 168h 0% left

That means the provider auth is valid, but the provider has no usage left, which is very likely why the agent won’t answer now.

So the situation looks like this

#

Old problem: invalid agentmail config, probably fixed by Doctor
Current problem: provider usage exhausted

Best next step

Switch to another provider/model with available usage, then:

/new

and retry the Gmail flow.

If you want logs, I only need fresh logs from a new test, not the older startup errors:

openclaw logs --follow

#

Then send one dashboard message and paste the lines that appear right after that.

Docs: https://docs.openclaw.ai/concepts/models

Glad we caught the log mismatch, that saves a lot of chasing the wrong thing.

#

Yep, that is still the same old startup error.

The key clue is the timestamp block, it’s all from around 00:01, so it’s still the earlier config failure, not the current live issue.

Right now the picture is:

Config loads now (openclaw status works)
Auth loads now (openclaw models status works)
Provider usage is exhausted (0% left)

So I would stop chasing the old agentmail log lines for the moment. The likely blocker now is still the provider quota.

Next real step

switch to another provider/model with available usage, or wait for reset
then start a fresh session with:

#

  /new

then retry the Gmail setup

If you want fresh logs after that, do this exact sequence:

openclaw logs --follow

then send one new dashboard message, and paste only the new lines that appear after that.

Docs: https://docs.openclaw.ai/concepts/models

I know this is annoying, but I’m pretty confident the old log spam is a distraction now.

cunning knoll Apr 21, 2026, 1:12 AM

#

So, I need to check with chatgpt for reset times?

ruby spruceBOT Apr 21, 2026, 1:13 AM

#

No, you shouldn’t need ChatGPT for that.

openclaw models status already gave you the reset timer:

0% left ⏱6d 11h

So the provider is basically saying, “no usage left, resets in about 6 days 11 hours.”

Practical options

wait for that reset, or
switch to another provider/model now, then do /new and continue

If you want live advice on what people are using successfully right now, ask in #models too.
Docs: https://docs.openclaw.ai/concepts/models

#

If you switch providers and want me to sanity-check the next step before you retry Gmail, I can do that.

cunning knoll Apr 21, 2026, 1:41 PM

#

I did get a subscription for google gemini to get me back up and running for now. What do I need to change to point to the new model?

ruby spruceBOT Apr 21, 2026, 1:42 PM

#

Yep. A couple of important nuances first:

If you mean a Gemini Advanced subscription, that alone is not automatically OpenClaw auth.
For OpenClaw you need either:

a Gemini API key (google provider), or
Gemini CLI OAuth (google-gemini-cli provider)

Fastest path

If you have an API key, do:

openclaw onboard --auth-choice gemini-api-key
openclaw models list --provider google
openclaw models set <provider/model>

#

If you want to switch it just in the current chat/session, use:

/model

and pick the Google provider there.

If you want it to stick for new sessions

openclaw models set <provider/model> updates the default model.
Equivalent config key is:

agents.defaults.model.primary

After switching

#

Start a fresh session:

/new

Then retry the Gmail setup.

If `/model` says “not allowed”

That means you have an allowlist under agents.defaults.models, and you’ll need to add the Google model there or remove the allowlist.

Docs:

If you want, I can help you figure out whether you have API key access or need the Gemini CLI OAuth path.

cunning knoll Apr 21, 2026, 1:45 PM

#

I got the Google AI Plus subscription, and am using ollama

ruby spruceBOT Apr 21, 2026, 1:46 PM

#

Got it. In that case, the important bit is:

Google AI Plus is not the same thing as a Gemini API key for OpenClaw.

So you’ve basically got 2 paths:

Option 1, recommended

Use a real OpenClaw-compatible Google auth method:

Gemini API key (GEMINI_API_KEY / GOOGLE_API_KEY), or
Gemini CLI OAuth (google-gemini-cli)

Then switch with:

openclaw models list --provider google

#

openclaw models set <provider/model>

or in chat:

/model

Option 2, keep using Ollama

You can point OpenClaw at your Ollama model instead:

openclaw models list --provider ollama
openclaw models set <provider/model>

#

or use /model in chat.

But, for the kind of tool-heavy/agentic work you’re doing, Ollama models are often rougher and less reliable than cloud providers. I’d use Ollama for lighter chat, not as my first choice for this Gmail setup flow.

My recommendation

If you want the smoothest recovery, use Google API key or Gemini CLI OAuth, not just the Google AI Plus subscription.

Docs:

If you want, I can help you choose the faster path between Gemini API key and staying on Ollama.

cunning knoll Apr 21, 2026, 1:55 PM

#

I will only be using this subscription temporarily. Once my openai oauth usage resets, I will go back to using openai. I would also like to keep with ollama. Once I can move this setup to a more powerful computer, I will be strictly using local models.

ruby spruceBOT Apr 21, 2026, 1:55 PM

#

That’s a sensible plan.

Since the Google piece is temporary, I’d keep it simple and use a session-level switch, not a big permanent config rewrite:

What I’d do

keep OpenAI auth as-is
add temporary Google auth
use /model to switch this session to Google
keep Ollama available as a backup / experiment path
when OpenAI usage resets, use /model again to switch back

That way you are not constantly rewriting defaults.

My one caution

I’m glad you have the local-model plan, but for tool-heavy agent work like this Gmail setup, Ollama/local models are still usually rough unless the machine is pretty serious. I’d treat local as a good long-term goal, just not the most reliable short-term fix for this exact task.

If you want the default changed globally instead

#

Use:

openclaw models set <provider/model>

But for your temporary setup, I really think /model is the cleaner move.

If /model says the Google or Ollama option is “not allowed”, then you’ve got a model allowlist in config and we can fix that next.

cunning knoll Apr 21, 2026, 2:06 PM

#

I can't seem to change the model in the dashboard chat. gpt-5.4 is the only one shown. Do I need to set ollama to see the new model first? Can you give me the steps to switch the model openclaw uses from gpt-5.4 to the new one?

ruby spruceBOT Apr 21, 2026, 2:06 PM

#

Yep, if the dashboard only shows one option, OpenClaw does not have the new provider/model configured yet, or it’s being hidden by a model allowlist.

And no, you do not need to set Ollama first unless you want to use Ollama.

If you want to switch to Google temporarily

1) Add Google auth

If you have a Gemini API key:

openclaw onboard --auth-choice gemini-api-key

If you want the Gemini CLI OAuth path instead:

#

openclaw models auth login --provider google-gemini-cli --set-default

2) Check that OpenClaw can see Google models

openclaw models list --provider google

or for CLI OAuth:

openclaw models list --provider google-gemini-cli

3) Set the default model

#

openclaw models set <provider/model>

4) Start a fresh chat/session

/new

If you want to switch to Ollama instead

First make sure Ollama is actually running and has a model pulled, then:

#

openclaw models list --provider ollama
openclaw models set <provider/model>

Then /new.

Important

If the dashboard still only shows the old one after that, you probably have an allowlist under agents.defaults.models.

So the shortest debug loop is:

openclaw models list --provider google

#

openclaw models status

Paste those and I can tell you exactly what’s missing.

Docs:

cunning knoll Apr 21, 2026, 2:59 PM

#

michael@AInchor:~$ openclaw models list --provider google

🦞 OpenClaw 2026.4.15 (041266a) — Runs on a Raspberry Pi. Dreams of a rack in Iceland.

No models found.
michael@AInchor:~$
michael@AInchor:~$ openclaw models status

🦞 OpenClaw 2026.4.15 (041266a) — I keep secrets like a vault... unless you print them in debug logs again.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/gemini-3-flash-preview:cloud
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (2): openai-codex/gpt-5.4, ollama/gemini-3-flash-preview:cloud

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): openai-codex (1)

ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json
openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:gravity66726@yahoo.com=OAuth (gravity66726@yahoo.com)

OAuth/token status

openai-codex usage: 168h 0% left ⏱5d 21h
- openai-codex:gravity66726@yahoo.com (gravity66726@yahoo.com) ok expires in 9d

ruby spruceBOT Apr 21, 2026, 3:00 PM

#

This is actually pretty revealing:

Default : ollama/gemini-3-flash-preview:cloud

So you already switched away from gpt-5.4.
OpenClaw is currently pointed at an Ollama model, not the OpenAI one.

And this:

openclaw models list --provider google
No models found.

means the real Google provider is not configured at all.

#

So the current state is

Not using gpt-5.4 as default anymore
Not using Google provider either
Using Ollama as the default provider

That gemini-3-flash-preview:cloud name is just the model ref under Ollama. It does not mean OpenClaw is using your Google subscription.

What this means for you

If you want to use Ollama for now

You do not need to switch models again, it’s already switched.

At that point, if replies are still bad/stuck, the problem is probably:

the Ollama model/runtime itself
or the model just not being great at tool-heavy agent work

#

If you want to use actual Google temporarily

You still need to configure the Google provider first. Right now OpenClaw has no Google models available.

Docs:

My recommendation

Since you’re already on Ollama now, I’d do one quick test in a fresh session:

/new

then send a very simple message like hi.

If that still hangs, we’ve confirmed the issue is no longer model switching, it’s the current Ollama path.

cunning knoll Apr 21, 2026, 3:29 PM

#

I was under the assumption that adding a second provider would alleviate the openai-codex usage lockout. I believe that openclaw keeps wedging due to a tool call? It seems like when I open the dashboard, a heartbeat check is locking things up. When I run openclaw tui, I see: Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or
repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.
When reading HEARTBEAT.md, use workspace file
/home/michael/.openclaw/workspace/HEARTBEAT.md (exact case). Do not read
docs/heartbeat.md.
Current time: Tuesday, April 21st, 2026 - 10:58 AM (America/New_York) / 2026-04-21 14:58
UTC

400 {"error":"Function call is missing a thought_signature in functionCall parts. (ref:
847632ec-9dc9-49d5-a8d4-1f5cbdf213c3)"}

ruby spruceBOT Apr 21, 2026, 3:30 PM

#

Yep, this changes the diagnosis a bit.

I don’t think the heartbeat itself is the real bug. The heartbeat is just what’s triggering the bad session state.

That error:

400 {"error":"Function call is missing a thought_signature in functionCall parts"}

looks like a stale/corrupted session transcript, usually after an aborted partial stream. Switching providers does not automatically clean that up.

What I’d do now

1) Temporarily disable heartbeat

While debugging, this is worth doing so it stops auto-triggering:

#

{
  agents: {
    defaults: {
      heartbeat: { every: "0m" }
    }
  }
}

Then restart:

openclaw gateway restart

2) Start a brand new session

#

Do not reuse the wedged one:

/new

3) Turn thinking off in that new session

Per the FAQ, this is the right next move for thought-signature issues:

/thinking off

4) Send a tiny test message

Just:

#

hi

If that works, then retry the Gmail flow.

Important nuance

Adding a second provider helps only for new runs that actually use that provider.
It does not repair broken history already sitting in the current session.

Docs:

I’m pretty confident the next clean test should be: disable heartbeat, /new, /thinking off, then test.

cunning knoll Apr 21, 2026, 3:44 PM

#

If I just change ollama back to pointing to the chatgpt model, and restore my openclaw.json to the previous version before I tried to change the model, then wait the 6 days. Should this fix my issues? Assuming that my only real issue for the overflow was my mistake in setting up the oauth client type that started this. I'm afraid that some of the changes I need to make are beyond the scope of my computer knowledge and I will only create further harm.

ruby spruceBOT Apr 21, 2026, 3:45 PM

#

I’d take the conservative path, but with one important correction:

Do not restore the old openclaw.json wholesale if that was the version with the bad agentmail entry. That can put you right back into the invalid-config state.

And I also would not try to make Ollama “point to ChatGPT”. Those are separate providers.

Safest plan

Keep the current doctor-fixed config
It at least parses and starts.
Stop changing providers/models for now
You’re right that too many moving parts is making this harder.
Temporarily disable heartbeat
So it stops poking the wedged session while you wait:

#

   agents.defaults.heartbeat.every: "0m"

Wait for the OpenAI usage reset
After reset, switch back cleanly
Use /model or:
```
openclaw models set <openai-provider/model>
```
not a full config restore
Start a brand new session

#

   /new

and I’d also do:

/thinking off

My honest read

Yes, I think your original OAuth client-type mistake probably kicked off the mess, and then the later model/provider changes piled on top of it.

So your instinct, “make fewer changes, wait, then come back cleanly,” is actually a good one.

The only part I’d avoid is restoring the old config file blindly.

If you want, I can give you the lowest-risk exact steps to disable heartbeat now and then switch back later, without editing more than one tiny thing.

cunning knoll Apr 21, 2026, 3:47 PM

#

please give me those steps

ruby spruceBOT Apr 21, 2026, 3:48 PM

#

Yep. Here’s the lowest-risk path I’d use.

Right now, do only these steps

1) Make a safety copy of your current config

This is just a backup of the current doctor-fixed file:

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.safe-$(date +%Y%m%d-%H%M%S)

2) Disable heartbeat for now

This stops the automatic heartbeat run from poking the wedged session:

openclaw config set agents.defaults.heartbeat.every "0m"

#

3) Restart the gateway

openclaw gateway restart

4) Open the dashboard and start a brand new session

In the chat:

/new

5) Turn thinking off in that new session

/thinking off

#

At that point, I would stop making changes and just wait for the OpenAI usage reset.

When the OpenAI usage resets

6) Do not restore the old config file

Do not copy openclaw.json.bak back over the live config.

Instead, switch models cleanly with the picker:

/model

and choose your old OpenAI entry there.

#

If you prefer CLI, use:

openclaw models list
openclaw models set <the OpenAI entry from the list>

7) Start one more fresh session

/new

Then test with a tiny message like:

hi

#

Important

Please do not do a full config restore.
That is the one step most likely to bring back the invalid agentmail config.

If any one of the commands above gives an error, stop there and paste just that error. That’s the safest way to keep this from snowballing.

cunning knoll Apr 21, 2026, 7:10 PM

#

I upgraded my chatgpt subscription, and when I ran openclaw status I saw:
michael@AInchor:~$ openclaw models status

🦞 OpenClaw 2026.4.15 (041266a)
The only open-source project where the mascot could eat the competition.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.4
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (2): openai-codex/gpt-5.4, ollama/gemini-3-flash-preview:cloud

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): openai-codex (1)

ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json
openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:gravity66726@yahoo.com=OAuth (gravity66726@yahoo.com)

OAuth/token status

openai-codex usage: 5h 100% left ⏱4h 59m · Week 100% left ⏱6d 23h
- openai-codex:gravity66726@yahoo.com (gravity66726@yahoo.com) ok expires in 9d
  Does it look like the initial issue is resolved?

ruby spruceBOT Apr 21, 2026, 7:10 PM

#

Yep, this looks much better.

The important part is:

usage: 5h 100% left ... Week 100% left

So the OpenAI usage lockout is resolved. That was definitely one of the blockers before.

What this means

Model quota issue: looks fixed
Auth/token issue: looks fine
Config loads: also looks fine from this output

What it does not prove yet

It does not guarantee the old wedged session is healthy, or that the Gmail flow itself is fixed.

#

Best next test

Open the dashboard
Start a fresh session:
```
/new
```
I’d still do:
```
/thinking off
```
Send a tiny test like:
```
hi
```

If that works, then ask it to continue the Gmail setup again.

#

So short version: yes, the lockout problem looks resolved.
Now the next question is just whether a clean new session works normally.

cunning knoll Apr 21, 2026, 7:14 PM

#

A new session has started, and I seem to be back in contact with the agent. I will mark this as answered and work with the agent to clean up the mail install.

ruby spruceBOT Apr 21, 2026, 7:15 PM

#

Nice, that’s a relief 😌

That strongly suggests the big blocker was the wedged old session + usage lockout, not a permanently broken install.

And yep, if this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

If the Gmail cleanup hits another snag, just post the new/current error only and we can debug from the clean state instead of dragging the old thread history along.

#Setting up email API, locked out.

What I’d do next

Next 2 checks

Why I think it’s the session

What to do next

One more confirmation check

So the situation looks like this

Best next step

Next real step

Practical options

Fastest path

If you want it to stick for new sessions

After switching

If /model says “not allowed”

Option 1, recommended

Option 2, keep using Ollama

My recommendation

What I’d do

My one caution

If you want the default changed globally instead

If you want to switch to Google temporarily

1) Add Google auth

2) Check that OpenClaw can see Google models

3) Set the default model

4) Start a fresh chat/session

If you want to switch to Ollama instead

Important

So the current state is

What this means for you

If you want to use Ollama for now

If you want to use actual Google temporarily

My recommendation

What I’d do now

1) Temporarily disable heartbeat

2) Start a brand new session

3) Turn thinking off in that new session

4) Send a tiny test message

Important nuance

Safest plan

My honest read

Right now, do only these steps

1) Make a safety copy of your current config

2) Disable heartbeat for now

3) Restart the gateway

4) Open the dashboard and start a brand new session

5) Turn thinking off in that new session

When the OpenAI usage resets

6) Do not restore the old config file

7) Start one more fresh session

Important

What this means

What it does not prove yet

Best next test

If `/model` says “not allowed”