Not able to enter the local | Friends of the Crustacean 🦞🤝 | Page 1

wheat tulip Mar 6, 2026, 11:47 AM

#

Config overwrite: /home/yogesh/.openclaw/openclaw.json (sha256 4a871cc43790d40e881f5789c73f58fc07f49c67b47b32b619c6c6e7e3afd13d -> d1ede99997b0a02dd415e52598aade5e7bfc44de1b7627941cbb8d91acea5915, backup=/home/yogesh/.openclaw/openclaw.json.bak)
│
◇ Gateway service runtime ────────────────────────────────────────────╮
│ │
│ QuickStart uses Node for the Gateway service (stable + supported). │
│ │
├──────────────────────────────────────────────────────────────────────╯
Error: systemctl is-enabled unavailable: Command failed: systemctl --user is-enabled openclaw-gateway.service

cerulean mesaBOT Mar 6, 2026, 11:47 AM

#

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

neat orbitBOT Mar 6, 2026, 11:49 AM

#

That error isn’t “OpenClaw can’t run” — it’s “QuickStart tried to install/check the systemd user service, but systemctl --user … isn’t available in your environment”.

Most common causes + fixes:

1) You’re in WSL2 and systemd is not enabled

Enable systemd (per docs), then retry openclaw gateway install / openclaw onboard --install-daemon:

https://docs.openclaw.ai/platforms/windows (see “Enable systemd (required for gateway install)”)

2) You’re in a container / distro without systemd (or `systemctl` isn’t usable)

In that case the daemon install won’t work. Just run the gateway directly (it’s the same process, just not supervised by systemd):

openclaw gateway --port 18789 --verbose
Runbook: https://docs.openclaw.ai/gateway

Quick triage (paste output)

Can you paste these?

#

openclaw --version
cat /etc/os-release
ps -p 1 -o comm=
which systemctl && systemctl --user status 2>&1 | head -50

That’ll tell us immediately if it’s WSL-without-systemd vs “no systemd at all” vs “systemd present but user services not reachable”.

wheat tulip Mar 6, 2026, 11:50 AM

#

yogesh@DESKTOP-HRDPM2M:/mnt/c/Users/i-genie techoholics$ openclaw --version
cat /etc/os-release
ps -p 1 -o comm=
which systemctl && systemctl --user status 2>&1 | head -50
2026.3.2
PRETTY_NAME="Ubuntu 24.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.4 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo
systemd
/usr/bin/systemctl
● DESKTOP-HRDPM2M
State: running
Units: 158 loaded (incl. loaded aliases)
Jobs: 0 queued
Failed: 0 units
Since: Fri 2026-03-06 11:39:34 UTC; 10min ago
systemd: 255.4-1ubuntu8.12
CGroup: /user.slice/user-1000.slice/user@1000.service
└─init.scope
├─215 /usr/lib/systemd/systemd --user
└─218 "(sd-pam)"

neat orbitBOT Mar 6, 2026, 11:51 AM

#

Nice — that output confirms you’re on WSL Ubuntu 24.04 and systemd user mode is working (ps -p 1 is systemd, and systemctl --user status works).

So your original QuickStart error is almost certainly just this:

systemctl --user is-enabled openclaw-gateway.service is failing because the unit file doesn’t exist yet (not because systemctl is “missing”).

Fix: install the gateway unit, then enable it

Run:

openclaw gateway install
systemctl --user daemon-reload
systemctl --user enable --now openclaw-gateway.service

openclaw gateway status
openclaw logs --follow

#

If you just want to verify everything works before messing with services, you can also do:

openclaw gateway --port 18789 --verbose

(in a terminal you keep open)

If it still errors, paste these two outputs

systemctl --user is-enabled openclaw-gateway.service
systemctl --user status openclaw-gateway.service --no-pager

(Also: your old config is still in /home/yogesh/.openclaw/openclaw.json.bak if you need to diff/restore anything.)

wheat tulip Mar 6, 2026, 11:52 AM

#

🦞 OpenClaw 2026.3.2 (85377a2)
I don't have opinions about tabs vs spaces. I have opinions about everything else.

Gateway service check failed: Error: systemctl is-enabled unavailable: Command failed: systemctl --user is-enabled openclaw-gateway.service
Failed to enable unit: Unit file openclaw-gateway.service does not exist.

🦞 OpenClaw 2026.3.2 (85377a2) — Making 'I'll automate that later' happen now.

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-03-06.log

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH is not set; the daemon should use a minimal PATH.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state inactive, sub dead, last exit 0, reason 0)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /home/yogesh/.openclaw/openclaw.json

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

🦞 OpenClaw 2026.3.2 (85377a2)
I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/yogesh/.openclaw/openclaw.json
Bind: loopback
Hint: run openclaw doctor.

neat orbitBOT Mar 6, 2026, 11:52 AM

#

Yep, that output is actually super clear:

Failed to enable unit: Unit file openclaw-gateway.service does not exist.
⇒ the systemd unit file was never created (or you still have an old unit name from pre-OpenClaw days).
Service config looks out of date or non-standard … PATH is not set
⇒ strongly suggests there’s some legacy gateway service hanging around (e.g. clawdbot-* / moltbot-*) and the current installer wants to migrate it.

Do this (it’s exactly what the CLI recommends)

openclaw doctor --repair

Then check what unit names you actually have:

systemctl --user list-unit-files | grep -E 'openclaw|clawdbot|moltbot'

#

If you see an old one (like clawdbot-gateway.service), paste that list here and we’ll tell you which one to enable/disable.

If you want to bypass systemd for now (to keep moving)

Run the gateway in the foreground:

openclaw gateway run --port 18789 --verbose

Then open: http://127.0.0.1:18789/

If `doctor --repair` doesn’t create the unit

Try forcing the install explicitly:

openclaw gateway install --force

Paste the output of openclaw doctor --repair (and the list-unit-files | grep … line) if it still doesn’t land.

wheat tulip Mar 6, 2026, 11:57 AM

#

┌ OpenClaw doctor │
│ - 4/5 recent sessions are missing transcripts. │
│ Verify sessions in store: openclaw sessions --store │
│ "/home/yogesh/.openclaw/agents/main/sessions/sessions.json" │
│ Preview cleanup impact: openclaw sessions cleanup --store │
│ "/home/yogesh/.openclaw/agents/main/sessions/sessions.json" │
│ --dry-run │
│ Prune missing entries: openclaw sessions cleanup --store │
│ "/home/yogesh/.openclaw/agents/main/sessions/sessions.json" │
│ --enforce --fix-missing │
│ - Found 2614 orphan transcript file(s) in │
│ ~/.openclaw/agents/main/sessions. They are not referenced by │
│ sessions.json and can consume disk over time. │

◇ Doctor changes │ - Archived 2614 orphan transcript file(s) in │
│ ~/.openclaw/agents/main/sessions │

◇ Securit
│ - No channel security warnings detected. │
│ - Run: openclaw security audit --deep │

◇ Skills status ────────────╮
│ │
│ Eligible: 12 │
│ Missing requirements: 40 │
│ Blocked by allowlist: 0 │

◇ Plugins ──────╮
│ │
│ Loaded: 5 │
│ Disabled: 33 │
│ Errors: 0 │
◇ Gateway ──────────────╮
│ │
│ Gateway not running. │

◇ Gateway connection ─
│ │
│ Gateway target: ws://127.0.0.1:18789 │
│ Source: local loopback │
│ Config: /home/yogesh/.openclaw/openclaw.json │
│ Bind: loopback │
◇ Gateway ─

│ Gateway service not installed. │

Installed systemd service: /home/yogesh/.config/systemd/user/openclaw-gateway.service
│
└ Doctor complete.

neat orbitBOT Mar 6, 2026, 11:57 AM

#

Perfect — openclaw doctor did the important part: it created the unit file:

/home/yogesh/.config/systemd/user/openclaw-gateway.service

Now you just need to enable + start it:

systemctl --user enable --now openclaw-gateway.service
openclaw gateway status

If the service starts but the probe still says failed, grab:

systemctl --user status openclaw-gateway.service --no-pager
openclaw logs --follow

#

Once openclaw gateway status shows Runtime: running + RPC probe: ok, the dashboard should work at:
http://127.0.0.1:18789/

wheat tulip Mar 6, 2026, 11:59 AM

#

I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-06.log
Command: /home/yogesh/.nvm/versions/node/v24.13.1/bin/node /home/yogesh/.nvm/versions/node/v24.13.1/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/yogesh/.nvm/versions/node/v24.13.1/bin/node)
Service config issue: System Node 22+ not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 2598, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

neat orbitBOT Mar 6, 2026, 11:59 AM

#

That’s the “all good” state:

Service: enabled
Runtime: running
RPC probe: ok
Listening: 127.0.0.1:18789

So you should now be able to open the Control UI at:

http://127.0.0.1:18789/ (or http://localhost:18789/ from Windows)

If you want the CLI to hand you the exact dashboard URL (often includes the auth token flow), run:

openclaw dashboard

About the remaining warning: the service is launching OpenClaw via an nvm Node path. It’s not breaking anything right now (since it’s running), it’s just a heads-up that it can break later if that nvm path changes. If/when you install a system Node 22+ and want to “harden” the service, rerun:

#

openclaw doctor --repair

If the dashboard loads for you now, please mark the solution (right-click the solution message → Apps → ✅ Mark Solution) so Answer Overflow indexes it.

wheat tulip Mar 6, 2026, 12:03 PM

#

│
│ Runtime: running (pid 2811, state active, sub running, last exit 0, │
│ reason 0) │
│ │
├───────────────────────────────────────────────────────────────────────╯
Restarted systemd service: openclaw-gateway.service
│
◇
│
◇ Gateway ──────────────╮
│ │
│ Gateway not running. │
│ │
├────────────────────────╯
│
◇ Gateway connection ───────────────────────────╮
│ │
│ Gateway target: ws://127.0.0.1:18789 │
│ Source: local loopback │
│ Config: /home/yogesh/.openclaw/openclaw.json │
│ Bind: loopback

neat orbitBOT Mar 6, 2026, 12:04 PM

#

That looks like the systemd service restarted, but the RPC probe couldn’t reach the gateway right after (either because the process crashed on startup, is still starting, or auth/connect failed).

Let’s get the exact reason from systemd + the file log (no secrets needed).

Run these and paste the output:

systemctl --user status openclaw-gateway.service --no-pager
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
tail -n 200 /tmp/openclaw/openclaw-2026-03-06.log

Also check whether the service is pointing at a Node binary that no longer exists (common with nvm after changes):

ls -la /home/yogesh/.nvm/versions/node/v24.13.1/bin/node

#

which node
node -v

If that ls fails, the fix is usually just: rerun openclaw doctor --repair (it will regenerate the unit to whatever Node/OpenClaw you currently have), then systemctl --user restart openclaw-gateway.service.

wheat tulip Mar 6, 2026, 12:06 PM

#

yogesh@DESKTOP-HRDPM2M:/mnt/c/Users/i-genie techoholics$ ls -la /home/yogesh/.nvm/versions/node/v24.13.1/bin/node
-rwxr-xr-x 1 yogesh yogesh 122523096 Feb 10 04:59 /home/yogesh/.nvm/versions/node/v24.13.1/bin/node
yogesh@DESKTOP-HRDPM2M:/mnt/c/Users/i-genie techoholics$ which node
node -v
/home/yogesh/.nvm/versions/node/v24.13.1/bin/node
v24.13.1

neat orbitBOT Mar 6, 2026, 12:06 PM

#

Cool — Node/nvm isn’t the problem (the binary exists and node -v matches what the service is pinned to).

Next we need the actual service failure reason (or confirm it’s just a probe/auth/connect issue). Please paste these:

openclaw gateway status --deep
systemctl --user status openclaw-gateway.service --no-pager
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
tail -n 200 /tmp/openclaw/openclaw-2026-03-06.log

If you want the fastest “what is the gateway complaining about” signal (bypasses systemd entirely), also run in a terminal:

openclaw gateway run --port 18789 --verbose

#

That usually prints the exact config/plugin/channel error immediately.

wheat tulip Mar 6, 2026, 12:07 PM

#

🦞 OpenClaw 2026.3.2 (85377a2)
I read logs so you can keep pretending you don't have to.

12:07:29 Gateway failed to start: gateway already running (pid 2837); lock timeout after 5000ms
If the gateway is supervised, stop it with: openclaw gateway stop
12:07:29 Port 18789 is already in use.
12:07:29 - pid 2837 yogesh: openclaw-gateway (127.0.0.1:18789)
12:07:29 - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
12:07:29 Gateway service appears enabled. Stop it first.
12:07:29 Tip: openclaw gateway stop
12:07:29 Or: systemctl --user stop openclaw-gateway.service ...

neat orbitBOT Mar 6, 2026, 12:10 PM

#

Good news: that message means the Gateway is already running and the port is taken by your existing systemd-managed instance:

pid 2837 … openclaw-gateway (127.0.0.1:18789)
Port 18789 is already in use

So what happened is: you tried to start a second gateway (e.g. via openclaw gateway run), and it correctly refused.

What to do

If you want to keep using the systemd service (recommended):

openclaw gateway status

Then open the UI: http://localhost:18789/ (or run openclaw dashboard)

If you want to run openclaw gateway run --verbose for debugging:
Stop the service first, then run it in the foreground:

#

openclaw gateway stop
openclaw gateway run --port 18789 --verbose

If openclaw gateway status still shows “RPC probe: failed” while the process is clearly running, paste the output of openclaw gateway status and we’ll narrow it to auth/url vs. something else.

wheat tulip Mar 6, 2026, 12:15 PM

#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-06.log
Command: /home/yogesh/.nvm/versions/node/v24.13.1/bin/node /home/yogesh/.nvm/versions/node/v24.13.1/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/yogesh/.nvm/versions/node/v24.13.1/bin/node)
Service config issue: System Node 22+ not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 2837, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

neat orbitBOT Mar 6, 2026, 12:15 PM

#

Yep — that’s the healthy end state. ✅

systemd service enabled
Gateway running
RPC probe: ok
listening on 127.0.0.1:18789
dashboard at http://127.0.0.1:18789/

So the original QuickStart error was just because the openclaw-gateway.service unit didn’t exist yet; openclaw doctor created it.

Re: the remaining “Node from a version manager” warning: you can ignore it as long as you don’t remove that nvm Node version. If you ever change Node versions, just rerun openclaw doctor --repair so the service gets repointed.

If this is all working for you now, please mark the solution message (right-click → Apps → ✅ Mark Solution) so Answer Overflow indexes it.

wheat tulip Mar 6, 2026, 12:21 PM

#

even i change the Codex email but stil showing api limit reach how can i check wether 2 openclaw running

neat orbitBOT Mar 6, 2026, 12:22 PM

#

Changing the “Codex email” text won’t change anything by itself — rate limits are tied to the actual credential/token OpenClaw is using, not a displayed email. So two things to check:

1) Make sure you’re actually logged in with the new Codex account

Re-run the Codex OAuth login flow (this is what switches accounts):

openclaw models auth login --provider openai-codex
openclaw models status --plain

In models status, look for which provider + profile is being selected for OpenAI/Codex. If you have multiple profiles, you may need to change the order (no secrets involved):

openclaw models auth order get --provider openai-codex
# (then set it to the profile id you want, as shown by `openclaw models status`)

#

Docs (Codex OAuth): https://docs.openclaw.ai/providers/openai

2) Check whether you accidentally have 2 OpenClaw gateways running

On your machine, these will tell you if there are multiple gateways/services:

openclaw gateway probe
openclaw gateway status --deep
ss -ltnp | grep 18789
ps aux | grep -E 'openclaw|openclaw-gateway' | grep -v grep

If you paste the output of openclaw models status --plain (just the provider/auth section — redact any tokens) and the exact “api limit reached” error line, I can tell you whether you’re hitting Codex subscription rate limits vs an API-key quota vs the wrong profile still being used.

wheat tulip Mar 6, 2026, 12:27 PM

#

Gateway Status
Reachable: no
Probe budget: 3000ms

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
Connect: ok (61ms) · RPC: failed - timeout

neat orbitBOT Mar 6, 2026, 12:28 PM

#

Connect: ok … RPC: failed - timeout usually isn’t “2 OpenClaw running” — it means the gateway accepted the WebSocket connection, but it didn’t answer the follow-up RPC within the probe budget (yours is only 3000ms).

1) First try a bigger probe timeout

openclaw gateway probe --timeout 15000
# or:
openclaw gateway status --timeout 15000

2) If it still times out, check if the systemd service is wedged + grab the last log lines

systemctl --user status openclaw-gateway.service --no-pager
tail -n 200 /tmp/openclaw/openclaw-2026-03-06.log

3) Quick “unstick” (safe) restart

#

systemctl --user restart openclaw-gateway.service

If you paste the output of systemctl --user status … + the last ~50–200 lines of that /tmp/openclaw/...log, we can usually see immediately why the gateway isn’t responding (startup loop, auth/secret resolution, channel/plugin hang, etc.).

wheat tulip Mar 6, 2026, 12:30 PM

#

Gateway Status
Reachable: yes
Probe budget: 3000ms

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
Connect: ok (111ms) · RPC: ok
Gateway: DESKTOP-HRDPM2M (172.19.110.131) · linux 6.6.87.2-microsoft-standard-WSL2 · app 2026.3.2
Wide-area discovery: unknown
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-06.log
Command: /home/yogesh/.nvm/versions/node/v24.13.1/bin/node /home/yogesh/.nvm/versions/node/v24.13.1/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/yogesh/.nvm/versions/node/v24.13.1/bin/node)
Service config issue: System Node 22+ not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 3356, state active, sub running, last exit 0, reason 0)
RPC probe: ok
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=3356,fd=27))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=3356,fd=28))
yogesh 3356 9.3 6.1 19082112 753368 ? Ssl 12:19 0:57 openclaw-gateway

neat orbitBOT Mar 6, 2026, 12:31 PM

#

Nice — that output answers the “2 OpenClaw running?” part:

Only one process is listening on the gateway port:
- LISTEN 127.0.0.1:18789 … pid=3356 openclaw-gateway
And gateway probe shows RPC: ok.

So your “api limit reached” is not because you have two gateways fighting each other locally.

For the “Codex email changed but still API limit reached”

Changing an email string won’t switch accounts/limits — you need to switch the actual Codex OAuth credential OpenClaw is using.

Do this:

openclaw models auth login --provider openai-codex
openclaw models status --plain

#

Then paste just the Auth overview / profile list part from openclaw models status --plain (please redact anything that looks like a token). That will tell us which profile is being picked, and whether you’re still on the old login.

Also paste the exact “api limit reached” error line (from the CLI output or /tmp/openclaw/openclaw-2026-03-06.log) so we can tell if it’s:

a Codex subscription rate limit (wait/reset), or
an API-key quota issue (needs a key/billing), or
the wrong provider/profile still being selected.

wheat tulip Mar 6, 2026, 12:32 PM

#

🦞 OpenClaw 2026.3.2 (85377a2)
I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

Error: No provider plugins found. Install one via openclaw plugins install.

🦞 OpenClaw 2026.3.2 (85377a2)
iMessage green bubble energy, but for everyone.

openai-codex/gpt-5.1

neat orbitBOT Mar 6, 2026, 12:33 PM

#

That error is the key:

Error: No provider plugins found. Install one via openclaw plugins install.

openclaw models auth login … only works when the provider auth plugin is available/enabled. Right now OpenClaw isn’t seeing any provider-auth plugins, so it can’t run the Codex OAuth flow (changing “Codex email” won’t matter until the auth plugin is working).

Step 1: see what plugins you actually have (and whether the auth ones are disabled)

Run and paste the output:

openclaw plugins list
openclaw plugins list | grep -i -E "auth|openai|codex|provider|oauth"

Step 2: enable the relevant auth plugin (once we know its id)

When we see the plugin id in your list, you’ll do:

#

openclaw plugins enable <pluginId>
systemctl --user restart openclaw-gateway.service

Step 3: retry Codex OAuth

openclaw models auth login --provider openai-codex

If openclaw plugins list shows nothing related to provider auth at all, then your OpenClaw install may be missing the bundled extensions (in that case, tell me how you installed it: npm i -g, from git+pnpm, etc., and we’ll fix the install path).

wheat tulip Mar 6, 2026, 12:40 PM

#

how to install? there is no specific name and ID available

neat orbitBOT Mar 6, 2026, 12:42 PM

#

For OpenAI Codex OAuth you don’t need to install a plugin. The login flow is built into OpenClaw (docs call it out explicitly):
https://docs.openclaw.ai/providers/openai and https://docs.openclaw.ai/concepts/oauth

That “No provider plugins found” message usually happens when the provider id you passed doesn’t match a built‑in login flow, so it falls back to “plugin auth flows”… and you have none.

Make sure you’re using the provider id (not the model id)

This is correct (provider only):

openclaw models auth login --provider openai-codex

This is wrong (provider+model):

openai-codex/gpt-5.1   # <-- that’s a model ref, not a provider id for auth login

Easiest path (wizard)

#

openclaw onboard --auth-choice openai-codex

Can you paste the exact command you ran that produced “No provider plugins found”? (No tokens / no URLs with codes — just the command text + the error.)

wheat tulip Mar 6, 2026, 12:48 PM

#

onfig : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.1
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : GPT -> openai/gpt-5.1-codex, gemma-3-1b -> lmstudio/google/gemma-3-1b
Configured models (6): openai/gpt-5.1-codex, openai-codex/gpt-5.3-codex, lmstudio/google/gemma-3-1b, lmstudio/gemma-3-1b, openai-codex/gpt-5.1, openai-codex/gpt-5.1-codex-mini

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

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | anthropic:default=sk-or-v1...df6ed8cd
google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyBo...xpUpohf8
lmstudio effective=models.json:a...c | models.json=a...c | source=models.json: ~/.openclaw/agents/main/agent/models.json
openai effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openai:default= source=env: OPENAI_API_KEY
openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:default=OAuth
openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...df6ed8cd

OAuth/token status

openai-codex
- openai-codex:default ok expires in 10d

neat orbitBOT Mar 6, 2026, 12:48 PM

#

Thanks — this output shows your setup is actually fine:

Default model: openai-codex/gpt-5.1
openai-codex:default = OAuth, expires in 10d (ok)

So you do not need to install any provider plugin for Codex OAuth — you already have it working.

About “API limit reached”

At this point it’s almost certainly a provider-side rate limit/quota, not “two OpenClaw instances”. The next thing we need is the exact error line when it happens (429 / rate_limit / quota / etc) and which provider it comes from.

Run this, then trigger one request that fails, then paste the error block:

openclaw logs --follow

Important (security)

You pasted partial API keys in a public thread (sk-..., AIza...). Even if truncated, please don’t paste keys here. If you accidentally pasted any full key earlier, rotate it.

#Not able to enter the local

1) You’re in WSL2 and systemd is not enabled

2) You’re in a container / distro without systemd (or systemctl isn’t usable)

Quick triage (paste output)

Fix: install the gateway unit, then enable it

If it still errors, paste these two outputs

Do this (it’s exactly what the CLI recommends)

If you want to bypass systemd for now (to keep moving)

If doctor --repair doesn’t create the unit

What to do

1) Make sure you’re actually logged in with the new Codex account

2) Check whether you accidentally have 2 OpenClaw gateways running

1) First try a bigger probe timeout

2) If it still times out, check if the systemd service is wedged + grab the last log lines

3) Quick “unstick” (safe) restart

For the “Codex email changed but still API limit reached”

Step 1: see what plugins you actually have (and whether the auth ones are disabled)

Step 2: enable the relevant auth plugin (once we know its id)

Step 3: retry Codex OAuth

Make sure you’re using the provider id (not the model id)

Easiest path (wizard)

About “API limit reached”

Important (security)

2) You’re in a container / distro without systemd (or `systemctl` isn’t usable)

If `doctor --repair` doesn’t create the unit