#2 agents, 2 different openai oauth accounts

1 messages · Page 1 of 1 (latest)

lavish zinc
#

I am wanting to run 2 seprate agents, each with their own openai oauth. I set this up but new agent oauth using the terminal and oauth login but it doesnt seem to work. right now the response from the new agent is "detail":"not found"

worldly compassBOT
#

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

signal frostBOT
lavish zinc
#

from what my system is saying is a possible "codex request route" or request path. not config or service health

nimble juniperBOT
#

I’m checking the auth docs and source so I don’t hand-wave the fix.

#

Most likely cause: the second agent never got its own OAuth saved.

A couple important gotchas here:

  1. Auth is per-agent
    Each agent uses its own auth store at
    ~/.openclaw/agents/<agentId>/agent/auth-profiles.json
    Docs: https://docs.openclaw.ai/concepts/multi-agent and https://docs.openclaw.ai/concepts/oauth

  2. openclaw models auth login --provider openai-codex currently targets the default agent
    So if you ran the login from terminal, there’s a good chance it wrote creds to main, not your new agent.

  3. OpenAI OAuth is for openai-codex/*, not plain openai/*

#

Best fix

Re-run the agent wizard for the specific agent:

openclaw agents add <your-agent-id>

If it says the agent exists, choose Update it, then answer yes to:

Configure model/auth for this agent now?

Then log into openai-codex there.

Then verify

Please paste these:

# 
openclaw --version
openclaw agents list --bindings
openclaw models status --agent <your-agent-id> --probe --probe-provider openai-codex

Also, in the chat routed to that agent, run:

/model status

That will show which agent/model/profile it’s actually using.

If you want, send me those outputs and I’ll help pinpoint the exact break.

#

Let me check the Codex provider path in source.

#

Yeah, that actually does sound like a route/path issue, not generic service health.

For Codex OAuth, OpenClaw should use the built-in openai-codex route, which goes through chatgpt.com/backend-api. A thing I found in the current docs/source: old models.providers.openai-codex overrides can shadow that built-in path and cause 404-ish failures like {"detail":"not found"}.

The 2 big checks

  1. Make sure the agent is on openai-codex/*, not openai/*

    • good: openai-codex/gpt-5.4
    • not for OAuth: openai/gpt-5.4

  2. Check for stale models.providers.openai-codex overrides
    Especially bad signs are stuff like:

    • api: "openai-responses"
    • baseUrl: "https://api.openai.com/v1"

Those are legacy OpenAI transport settings, and docs say they can override the built-in Codex OAuth path.

#

Please run these and paste the output

openclaw --version
openclaw doctor
openclaw models status --agent <new-agent-id> --probe --probe-provider openai-codex

And if you can, paste this sanitized config snippet from openclaw.json:

models.providers.openai-codex

No secrets, just that section.

If openclaw doctor shows a Codex OAuth warning

lavish zinc
#

OpenClaw 2026.4.14 (323493f)

Agents:

  • main (default)
    Identity: 🐉 Herman (IDENTITY.md)
    Workspace: ~/.openclaw/workspace
    Agent dir: ~/.openclaw/agents/main/agent
    Model: openai-codex/gpt-5.4
    Routing rules: 0
    Routing: default (no explicit rules)
    Providers:
    • Discord default: configured
  • buffett (Buffett)
    Identity: Buffett (config)
    Workspace: ~/.openclaw/workspace-buffett
    Agent dir: ~/.openclaw/agents/buffett/agent
    Model: openai-codex/gpt-5.4
    Routing rules: 0
    Routing rules map channel/account/peer to an agent. Use --bindings for full rules.
    Channel status reflects local config/creds. For live health: openclaw channels status --probe.

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

  • openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=2, token=0, api_key=0)
nimble juniperBOT
#

That output is super useful, I’m checking why --agent buffett is still resolving main’s auth store.

#

This is the smoking gun.

You’ve got two issues mixed together:

  1. main is still the default agent
  2. buffett has 0 routing rules
  3. openclaw models auth login does not have an --agent target, so in this version it tends to write auth to the default agent, which is main

That lines up with why your second login didn’t behave like a clean per-agent OAuth.

Also, this line is suspicious:

- openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json

If you ran status for buffett, seeing main there is either:

#
  • the real auth target still being main, or
  • a misleading status/display bug in 2026.4.14

Either way, it’s bad news for the setup you want.

What I’d do next

1) Reconfigure buffett through the agent wizard

openclaw agents add buffett

If it says it already exists, choose Update, then choose:

Configure model/auth for this agent now? → yes

Then log into openai-codex with the second account there.

#

That path is agent-scoped. The plain terminal auth login is the part I don’t trust here.

2) Add explicit routing if you want Discord to hit buffett

Right now buffett has no routing rules, so Discord traffic will still fall back to main unless you bind something to buffett.

Docs: https://docs.openclaw.ai/concepts/multi-agent

3) Sanity check which auth profiles exist in each agent store

If you’re comfortable, paste just the profile IDs from both files, not the secrets:

  • ~/.openclaw/agents/main/agent/auth-profiles.json
  • ~/.openclaw/agents/buffett/agent/auth-profiles.json

My read

I don’t think you misconfigured this. I think you’ve hit a current limitation, maybe plus a status-path bug, in 2026.4.14.

If it still reproduces after using agents add buffett → Update → Configure model/auth, I’d file it here with the output you already pasted:

lavish zinc
#

is this a known bug?

nimble juniperBOT
#

I’m checking if there’s an existing issue for this exact multi-agent Codex OAuth behavior.

#

Yeah, this looks like known-bug territory, not just your setup.

I found a few very similar GitHub issues:

So, I can’t say your exact {"detail":"not found"} is already captured word-for-word, but multi-agent Codex OAuth weirdness definitely is.

Given your output, I think your case is probably a mix of:

  • non-default agent auth behavior being shaky
  • models auth login not being agent-targetable
  • possible status/auth-path confusion around main vs buffett
#

My recommendation

Since you’re on 2026.4.14 and still reproducing it, I’d file a fresh GitHub issue and link those related ones:

https://github.com/openclaw/openclaw/issues

Include:

  • openclaw --version
  • openclaw agents list
  • openclaw models status --agent buffett
  • the {"detail":"not found"} response
  • note that main is default and buffett is non-default
  • note that you authenticated the second account via terminal login

Short version

Yes, probably a real bug / limitation.
Not just you.