#Cron agent execution fail

1 messages · Page 1 of 1 (latest)

shut groveBOT
#

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

craggy valveBOT
#

Let me verify this against the current docs/source before I answer — auth/model resolution is one of those places where guessing gets people hurt.

#

First thing: can you paste openclaw --version? Cron/model auth behavior has changed recently.

Likely cause: gpt-mini is not a Codex OAuth model. In current docs, built-in gpt-mini resolves to:

openai/gpt-5.4-mini

That is the direct OpenAI API-key route, requiring OPENAI_API_KEY / OpenAI API auth.

But:

openai-codex/gpt-5.4-mini

is explicitly not supported for Codex OAuth. Codex OAuth should use:

# 
openai-codex/gpt-5.5

So the cron run fails because a fresh isolated cron execution resolves/validates the job model cleanly, instead of inheriting whatever your existing interactive session had cached/selected. The interactive session may “work” because it’s already pinned to a working model/auth/runtime, but the cron job is starting from its own job/default model selection.

Fix options:

# If you want Codex subscription/OAuth:
openclaw cron edit <job-id> --model openai-codex/gpt-5.5
openclaw models auth login --provider openai-codex

# If you specifically want GPT mini:
openclaw cron edit <job-id> --model openai/gpt-5.4-mini
# and make sure OPENAI_API_KEY / OpenAI API auth is configured for the Gateway
#

Yep — the handover theory is basically right, with one important correction:

openai-codex/gpt-5.4-mini is not a supported Codex OAuth route. Current docs say built-in gpt-mini is openai/gpt-5.4-mini — direct OpenAI API-key auth — while Codex OAuth should use openai-codex/gpt-5.5.

So there are two overlapping issues:

  1. Fresh cron run ≠ existing interactive session
    Cron starts a fresh agent run and resolves model/auth from config/session state. It does not prove the same thing as an already-running interactive session, which may have a pinned model, cached runtime, or different auth path.

  2. The effective Codex OAuth profile is bad/inherited
    The direct probe failing with openai-codex/gpt-5.5 means this is not just cron. OpenClaw is selecting the shared/main openai-codex OAuth profile, and OpenAI is rejecting that token as invalidated.

I’d fix in this order:

openclaw models status --agent CRON_AGENT --probe --probe-provider openai-codex --probe-timeout 60000
# 
openclaw models status --agent INTERACTIVE_AGENT --probe --probe-provider openai-codex --probe-timeout 60000

Then re-auth the agent store you actually want using the parent --agent position:

openclaw models auth --agent CRON_AGENT login --provider openai-codex --device-code

Not:

openclaw models auth login --agent CRON_AGENT ...

If you want Codex OAuth, set cron to:

craggy valveBOT
#

You’re not crazy — “listed” and “runnable with that auth route” are different things here. I should’ve phrased it more precisely.

What I mean is:

openai-codex/gpt-5.4-mini

may show up in a model list because it’s configured/discovered/forward-compat-visible, but current OpenClaw docs/source treat it as not a supported runnable Codex OAuth route.

The supported split is:

openai/gpt-5.4-mini        # mini via direct OpenAI API key
openai-codex/gpt-5.5       # Codex OAuth / ChatGPT subscription route
#

And current docs explicitly warn:

openai-codex/gpt-5.4-mini is not a supported Codex OAuth route

So what you’re missing is that /model list / models list is not a live guarantee. It can include configured rows or stale discovered rows. The actual cron execution still has to resolve a real provider transport + valid auth, and that’s where it falls over.

Also, current built-in gpt-mini should map to:

openai/gpt-5.4-mini

not:

# 
openai-codex/gpt-5.4-mini

If yours maps to the Codex version, check for a custom/stale alias:

openclaw config get agents.defaults.models
openclaw cron show <job-id>

For your cron:

  • Want mini → use openai/gpt-5.4-mini + OpenAI API key.
  • Want Codex OAuth → use openai-codex/gpt-5.5.

Separately, your probe showing token invalidated means the selected Codex OAuth profile is bad too — but even with good auth, I would not rely on openai-codex/gpt-5.4-mini for cron.

#

You’re right to push back. For your installed version (2026.4.24), that status is possible. I mixed in newer/current-source behavior too strongly.

Simplified:

  1. Your interactive session can run

    openai-codex/gpt-5.4-mini · oauth

    because OpenClaw 2026.4.24 still has a compatibility path that can map that model through Codex OAuth.

  2. Cron is failing because it starts fresh.
    A scheduled cron run has to load the stored OAuth profile again and start a new model call from scratch.

  3. Your stored OAuth credential appears bad/invalidated.
    The key clue is this direct probe also failed:

# 
   openai-codex/gpt-5.5 ... token has been invalidated

That means the stored Codex OAuth profile is broken, not just cron.

  1. Why chat still works:
    Your current chat may already have an in-memory/session-bound token/runtime that still works. Cron does not reuse that exact live state; it reloads auth from disk, hits the invalidated profile, and dies.

So the clean explanation is:

Interactive chat is running on an already-established session. Cron starts a new session and reuses the stored OAuth profile, and that stored profile is invalid.

Fix target: re-auth the actual agent auth store cron uses, then clear cooldown/auth-state and re-probe.

openclaw models auth --agent CRON_AGENT login --provider openai-codex --device-code
# 
openclaw models status --agent CRON_AGENT --probe --probe-provider openai-codex --probe-timeout 60000

And yes: my earlier “not supported” wording was too absolute for 2026.4.24. More accurate: it exists in your version, but it’s a compatibility-ish Codex OAuth route and the current failure is about fresh auth/profile selection, not proof the model can never run.

craggy valveBOT
#

Short version: no, fresh cron sessions are not supposed to be a perpetual problem.

A cron starting fresh just means: “load the model + auth profile from disk and start a new run.” That should work every time if the stored OAuth profile is valid.

So yes — re-auth + probe should fix it ongoing if you re-auth the same agent/profile the cron actually uses:

openclaw models auth --agent CRON_AGENT login --provider openai-codex --device-code
openclaw models status --agent CRON_AGENT --probe --probe-provider openai-codex --probe-timeout 60000

If that probe passes, cron should be able to start fresh runs.

Why gpt-5.5 works but gpt-mini doesn’t:

  • openai-codex/gpt-5.5 is the main Codex OAuth path and is better supported.
  • openai-codex/gpt-5.4-mini in your version appears to be a compatibility/discovered route. It may work in an existing session, but it’s more fragile for fresh resolution/auth.
#
  • If the error is “token invalidated”, that’s auth/profile selection — not cron inherently being unable to start new sessions.

Do you need to avoid gpt-mini for crons?
Not strictly, if this passes:

openclaw models status --agent CRON_AGENT --probe --probe-provider openai-codex --probe-timeout 60000

But my practical recommendation:

  • For Codex OAuth crons: use openai-codex/gpt-5.5
  • For mini/cost-saving crons: use openai/gpt-5.4-mini with an OpenAI API key

If gpt-5.5 works reliably for crons and only gpt-mini fails, I’d treat openai-codex/gpt-5.4-mini as not worth relying on for scheduled jobs.

#

You hit a real CLI mismatch — I gave you the wrong flag. In 2026.4.24, it’s not:

--device-code

It should be:

--method device-code

Try:

openclaw models auth login --provider openai-codex --method device-code
#

Since your status showed the cron was effectively using the shared/main auth profile, re-authing the default/main profile may be enough.

If you specifically need to write to CRON_AGENT: on 2026.4.24, the models auth --agent ... login path looks suspicious/possibly not honored. Best path is to update OpenClaw first, then run:

openclaw models auth --agent CRON_AGENT login --provider openai-codex --method device-code

Then verify with:

openclaw models status --agent CRON_AGENT --probe --probe-provider openai-codex --probe-timeout 60000

If that probe passes, cron should stop failing from fresh auth.

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

#

Yeah — this means the problem is not “cron starts fresh” by itself.

Think of it like this:

  • Your current chat is an already-open browser tab.
  • Cron/probe is a new login attempt from saved credentials.
  • The saved credential says: “token invalidated”.
  • The already-open tab can still work for a while because it already has live session state.

So when you say:

I can currently use openai-codex/gpt-5.5

that only proves the current running session can still talk to OpenAI. It does not prove the stored OAuth profile can start a new run.

The probe is the important truth for cron:

# 
openclaw models status --agent CRON_AGENT --probe --probe-provider openai-codex --probe-timeout 60000

If that fails, a fresh cron run can fail.

Why re-login may not be helping:

  1. 2026.4.24 has shaky --agent behavior for auth login.
    It may still be writing/using the default/main auth store, not the cron agent store.

  2. OpenClaw may still be selecting the old invalid profile via auth order/session state.

  3. The device-code login may not actually be replacing the profile that probe selects.

I’d do this next:

# 
openclaw models auth order clear --provider openai-codex --agent CRON_AGENT
openclaw models auth order clear --provider openai-codex --agent main
openclaw models auth login --provider openai-codex --method device-code
openclaw gateway restart
openclaw models status --agent CRON_AGENT --probe --probe-provider openai-codex --probe-timeout 60000

If that still fails, it’s no longer a cron mystery — it’s OpenClaw selecting or storing a bad Codex OAuth credential. At that point I’d update off 2026.4.24 first, because that version has enough auth/agent weirdness here to make debugging painful.

Why gpt-5.5 cron may work: it’s probably using a different stored profile/path/session than the failing gpt-mini cron. If the same agent + same openai-codex probe fails, then any fresh Codex OAuth cron is on shaky ground.

#

Yes — that does change the diagnosis.

If /new + selecting the same openai-codex/gpt-5.5 works, then this is not simply “saved OAuth is globally invalid.”

The clearer explanation is:

Your interactive /new session and your cron/probe are probably not using the same auth/profile path.

In 2026.4.24, the models status --agent ... --probe path looks misleading: the display may mention the requested agent, but the live probe can still hit the default/main auth store. So a failing probe can coexist with a working /new session.

So the question becomes: which auth store/profile does the cron run actually use?

Please check these:

openclaw cron show <job-id>
# 
openclaw cron runs --id <job-id> --limit 10
openclaw tasks show <run-id>

And in the working /new chat, run:

/model status

/model status is more useful than /status here because it should show the selected model/profile path.

What we’re trying to compare:

# 
working /new session:
  model = ?
  auth profile = ?
  auth-profiles.json path = ?

failing cron:
  model = ?
  auth profile = ?
  auth-profiles.json path = ?

If those paths differ, that explains everything: your interactive agent has valid Codex OAuth, while cron is picking a stale/main/shared profile.

Practical advice: update off 2026.4.24 if you can. This exact area — agent-scoped auth/probe/cron behavior — is too easy to misread in that version.

#

Use the cron job id, not the current chat/session id.

Find it with:

openclaw cron list

Look for the cron/reminder that’s failing. The leftmost/id column is the <job-id>.

Then run:

openclaw cron show <job-id>
openclaw cron runs --id <job-id> --limit 10
#

If you’re not sure which one it is, paste the output of:

openclaw cron list

redacting anything private.

The current item you see under gateway/sessions is a session key/session id; useful later, but for cron debugging we first need the cron job id from openclaw cron list.

#

You’re right — I blurred two threads there. Let’s separate them.

Main issue now: the probe is failing, and that may be unrelated to the cron job.

Since you can create a /new OpenClaw session and successfully use openai-codex/gpt-5.5 · oauth, the most likely problem is:

the probe command is not testing the same auth/profile/session path as your working chat.

So don’t chase the cron job id yet. First compare the working session’s actual model/auth profile against what the probe is testing.

In the working /new chat, run:

/model status

Then compare with:

# 
openclaw models status --probe --probe-provider openai-codex --probe-timeout 60000

If /model status shows one profile/path, and the probe is using another, that explains why chat works while probe fails.

After that, we can return to cron only if needed. The immediate mystery is: why does probe say the token is invalid while a fresh interactive session works?

craggy valveBOT
#

Yep, this is confusing because those two lines mean different things:

OAuth/token status = local credential looks present/usable.
It checks things like “do I have an OAuth profile/token stored?” and “does it look expired locally?”

Auth probe = real live model call.
It actually tries to use a stored profile to call OpenAI. That’s why it can fail with:

Your authentication token has been invalidated.

So OAuth/token status: OK can still coexist with auth probe: auth failed if OpenAI rejects that stored token server-side, or if the probe is testing a different/stale profile than your working session.

Given your sessions work, I’d interpret this as:

At least one stored openai-codex auth profile that the probe is testing is bad/stale, but your working chat is probably using a different valid profile/session path.

#

Next thing to compare:

In the working chat:

/model status

Look for the exact auth profile/path.

Then in CLI:

openclaw models status --probe --probe-provider openai-codex --probe-timeout 60000

Check which profile id the failing probe row names. If they differ, that’s the answer.

#

You can also force-probe one profile:

openclaw models status --probe --probe-provider openai-codex --probe-profile "openai-codex:PROFILE_ID" --probe-timeout 60000

One more wrinkle: on 2026.4.24, the probe/agent scoping around --agent looks suspect, so it may be probing main/default auth even when your working session uses another path. If you can update, I would — this is exactly the kind of auth-debugging weirdness that’s painful on that version.

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

#

You’re right — I gave you a bad command. Sorry. On Discord/native commands there isn’t a separate /model status command in your setup.

Use these instead:

  1. In the working chat, /status tells us the surface-level model/auth:
/status
  1. On the VPS, list recent sessions:
openclaw sessions --all-agents --active 120 --json

That will show the agentId, session key, and model for the working session.

  1. If we need the exact stored auth override, inspect the relevant sessions.json entry — don’t paste tokens/auth-profiles.json. Paste only fields like:
# 
key
model
modelProvider
providerOverride
modelOverride
authProfileOverride
authProfileOverrideSource

The key point: /status saying 🔑 oauth only means “OAuth route,” not necessarily which stored profile the failing probe is using. We need to compare the session’s selected model/profile-ish fields against the probe’s failing profileId row.

#

Good, this explains a lot.

Your working session is under:

agentId: claw
modelProvider: openai-codex
model: gpt-5.4-mini

And there is no authProfileOverride in that session, so it’s using whatever default OpenAI Codex profile/order the claw agent resolves at runtime.

Next: compare claw vs the failing probe/default path.

Run without probe first:

# 
openclaw models status --agent claw
openclaw models status --agent main

Look for the openai-codex effective=... / auth profile lines. If claw says OK and main is the one with the invalid token, then the answer is:

your working chat uses agent claw, but the auth probe / cron path is hitting main or another stale profile.

On 2026.4.24, I would not trust --probe --agent ... fully here; the probe path may still test the default/main store. The live session evidence is stronger.

If your cron is intended to run as claw, check the cron config next:

openclaw cron list
openclaw cron show <job-id>
#

We need to see whether that cron is actually bound to agentId: claw or some other/default agent.

#

That makes sense, and it narrows it down:

models status = inventory check.
It says: “I found an OAuth profile/token and it looks structurally OK.”

models status --probe = live call test.
It says: “I tried to use a profile for an actual model call, and OpenAI rejected that specific token.”

So the probe is not “extra info” from the same check — it’s a separate live request.

Given your working session is agentId: claw, the likely bug/quirk is:

--probe in 2026.4.24 is probably probing the default/main auth store or all stored openai-codex profiles, not necessarily the exact runtime path your working claw session uses.

So if sessions work and cron works with gpt-5.5, the failing probe row may be a stale profile somewhere else, not the active one.

Next useful step: identify the failing profile row in the probe output.

#

Run:

openclaw models status --probe --probe-provider openai-codex --probe-timeout 60000

Look in the Auth probes table for the failing row’s:

Profile / Label / Source

Then compare to what profile files exist:

find ~/.openclaw/agents -path '*/agent/auth-profiles.json' -print