#newly created agents no longer responding.

1 messages · Page 1 of 1 (latest)

coarse jacinthBOT
#

I’m checking the docs/code path first so I don’t make up config advice.

#

The docs layout changed a bit in the current checkout, so I’m locating the right FAQ/auth docs before I answer.

#

First thing, can you paste these:

openclaw --version
openclaw status --all
openclaw agents list --bindings
openclaw models status --agent <agent-id>

My first suspicion: regular multi-agent setups do not inherit main auth automatically. Each agent uses its own:

~/.openclaw/agents/<agentId>/agent/auth-profiles.json

A couple gotchas here:

#
  • If you pointed multiple agents at the same agentDir, that can cause auth/session collisions.
  • Only subagents get main auth as a fallback.
  • In TUI, openclaw tui usually talks to the default/current agent unless you launch it from that agent's workspace or explicitly target that agent/session.

So if openclaw models status --agent <agent-id> shows missing auth, that’s probably the issue. Give that agent its own agentDir, then copy/reconfigure auth for that agent instead of sharing the main one.

If you can, also run:

openclaw logs --follow

and paste any auth, bootstrapping, or session errors.

Docs:

hardy dew
#

the openclaw add agent command did indeed compy the auth profile from the main agent to the other agents. the api key is correct. also as i've mentioned they used to work yesterday

#

they meaining the new agents

coarse jacinthBOT
#

Let me narrow the likely failure mode a bit more before I point you at a fix.

#

Ah, got it, that helps. If the auth got copied and it worked yesterday, I’d stop blaming the API key.

The next likely suspects are:

  1. TUI is attached to the wrong agent/session
  2. that agent’s current session got stale
  3. gateway/session state is stuck

In the TUI, I’d try this first:

/status
/agent <agent-id>
/session agent:<agent-id>:main
/new
#

A couple important bits:

  • the TUI footer shows the current agent + session
  • openclaw tui can stay on the default agent unless you switch it
  • /new is the fastest way to rule out a stale/corrupted session

Then outside the TUI, run:

openclaw --version
openclaw status
openclaw models status --agent <agent-id>
openclaw logs --follow

What I’d look for:

#
  • tokens stay at 0 after sending a message, the agent never actually ran
  • models status --agent ... fails, that agent still has a per-agent model/auth problem
  • /new fixes it, the old session was the problem
  • logs mention bootstrapping, sessions, or trim/session file path stuff, then it’s probably session-store related

If /new does nothing, run this too:

openclaw doctor

If you paste:

  • openclaw --version
  • one failing agent id
  • the log lines right after a failed send

…I can narrow it down pretty fast.

#

Yep, I mean the new agents too.

Each new agent has its own session history, so even if auth is fine, that agent’s current session can still get stuck or stale independently of main.

So for one failing new agent, try:

/agent <new-agent-id>
/status
/new

If that fixes it, the problem was that new agent’s session, not auth.

If it still does nothing, paste these for that same new agent:

# 
openclaw models status --agent <new-agent-id>
openclaw logs --follow

At that point I’d be looking for session-store or bootstrapping errors, not API key issues.

hardy dew
#

you there?

/status

🦞 OpenClaw 2026.4.14 (323493f)
🧠 Model: openrouter/free · 🔑 api-key (openrouter:default)
📚 Context: 0/200k (0%) · 🧹 Compactions: 0
🧵 Session: agent:coder:tui-28be9665-c915-4a06-bf84-c928f5f7e8ff • updated just now
⚙️ Runtime: direct · Think: off
🪢 Queue: collect (depth 0)
connected | idle
agent coder (coder) | session tui-28be9665-c915-4a06-bf84-c928f5f7e8ff (openclaw-tui) |
openrouter/openrouter/free | think low | tokens ?/200k
this is the output. the tui says connected for a while, then it goes idle

coarse jacinthBOT
#

Yep, I’m here. Let me check whether openrouter/free is even a valid/expected model target in current docs/code, because that status line is suspicious.

#

Yep, that helps a lot.

connected | idle by itself is normal. The suspicious bit is that you send a message, it falls back to idle, and context stays at 0/200k. That usually means the run is getting rejected before a real turn starts.

A couple things stand out:

  • the TUI is definitely on the new agent now (agent:coder:...)
  • the model line is a little weird: openrouter/free / openrouter/openrouter/free instead of a concrete model

I’d try this inside the TUI:

/model status
/model list
/new
#

Then pick a concrete model from /model list, send a simple hi, and see if it replies.

At the same time, in another shell:

openclaw models status --agent coder
openclaw logs --follow

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

What I’d expect:

  • model not allowed / unknown model -> bad session model override
  • deprecated free model / OpenRouter error -> openrouter/free is the culprit
  • bootstrapping / session error -> session-store issue
hardy dew
#

hi

connected | idle
agent coder (coder) | session tui-28be9665-c915-4a06-bf84-c928f5f7e8ff (openclaw-tui) |
openrouter/nvidia/nemotron-3-super-120b-a12b:free | think medium | tokens ?/200k

coarse jacinthBOT
#

Okay, that rules out the weird generic openrouter/free path. Let me grab the exact agent CLI syntax from docs so I don’t guess.

#

Nice, that rules out the generic openrouter/free alias. If a concrete model still does nothing, I’d split TUI vs runtime next.

In another terminal, run this:

openclaw logs --follow

Then test the same agent without TUI:

openclaw agent --agent coder --message "hi" --json
openclaw agent --agent coder --message "hi" --local --json

That gives us a clean split:

#
  • first fails, second works -> gateway/TUI/session path problem
  • both fail -> agent workspace, model, or provider problem
  • both work -> TUI client issue

Also grab:

openclaw models status --agent coder

Please paste:

  • output of both openclaw agent ... commands
  • the log lines that appear right after
  • openclaw models status --agent coder

That should pinpoint it pretty fast.

hardy dew
#

10:46:15+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
10:46:15+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
10:46:15+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"pairing-required","handshake":"failed","durationMs":34,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"a3965145-c8e9-4d06-8502-aef1d1fd6607","host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":47778,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:47778->127.0.0.1:18789","deviceId":"6add61740b4245157c9543274d12fd4548495b433027b28b5901ccc73ee9ef00","requestId":"01f080e5-fdc1-4171-9f92-4cf2bd5eaba3","reason":"scope-upgrade"} closed before connect conn=28a5e7fd-075d-4c18-bd71-6ac4e400dfdf peer=127.0.0.1:47778->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=pairing required

coarse jacinthBOT
#

There it is. I’m checking the exact docs wording for the pairing required + scope-upgrade case so I can give you the right fix, not a guess.

#

Yep, found it. This is not the agent auth/profile problem.

The TUI client itself is getting blocked by the gateway:

  • pairing required
  • reason":"scope-upgrade"

So the TUI never finishes the gateway handshake, which is why it drops back to idle and the agent never runs.

Fix

Run:

openclaw devices list
openclaw devices approve 01f080e5-fdc1-4171-9f92-4cf2bd5eaba3
#

A couple notes:

  • if openclaw devices list shows a newer request id, approve that one instead
  • scope-upgrade means the device was already paired, but now it wants broader scopes

Then reconnect the TUI and try again.

If it still loops on pairing after approval, paste the output of:

openclaw devices list

and I’ll help with the next step. The fallback is usually removing that stale device pairing and re-approving it.

Docs:

hardy dew
#

10:53:11+00:00 info ⚠️ Agent couldn't generate a response. Please try again.

coarse jacinthBOT
#

That’s progress, weirdly. Pairing is probably no longer the blocker, and now the agent is at least getting far enough to fail normally. I’m checking where that exact fallback message comes from.

#

I want to see what triggers that fallback, because it’s a pretty generic “the run produced nothing visible” error.

#

Nice, that means the pairing issue is probably fixed.

This new message is a different failure: the agent is reaching the model, but OpenClaw isn’t getting a usable visible answer back. In current code that usually ends up being one of these:

  • reasoning-only turn with no visible reply
  • empty response
  • incomplete turn after retries

Quickest tests in TUI

/think off
/new
hi

If that works, the model was likely getting stuck in reasoning-only output.

#

If it still fails, switch that agent to a different model with:

/model list

and test again.

What to look for in logs

Reproduce once with openclaw logs --follow running and look for lines like:

  • reasoning-only assistant turn detected
  • empty response detected
  • reasoning-only retries exhausted

If you paste the 10 to 20 log lines before that Agent couldn't generate a response line, I can tell you which one it is.

hardy dew
#

10:57:29+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=c7b53931-9fb1-45f6-95a3-d96ed40a934d sessionId=bca27d22-e727-4126-8cf1-4220c226c5f0 stopReason=stop payloads=0 — surfacing error to user

coarse jacinthBOT
#

Perfect, that log is actually pretty decisive. I’m checking the exact incomplete-turn handling so I can translate it cleanly.

#

Yep, that confirms it.

stopReason=stop payloads=0 means the model run started and ended cleanly, but returned no visible text at all. So:

  • the new agent is running
  • pairing/auth is no longer the blocker
  • this is now a model/runtime output problem

In plain English, that model is basically saying “I’m done” without actually answering.

What I’d do next

  1. In TUI:
/think off
# 
/new
  1. Switch that agent to a different model with:
/model list
  1. Test again with a plain hi

If the new model works, then the issue is just that current model being flaky/incompatible here. Free OpenRouter picks can do this.

If you want to confirm the exact subtype, look for one of these right before that line in logs:

  • empty response retries exhausted
hardy dew
#

i did all of that, thing is that the main agent is working as expected

coarse jacinthBOT
#

Ah, that’s the key clue.

If main works and only the new agents fail, then the gateway/provider stack is probably fine. What’s left is per-agent state or workspace.

Best A/B check now

Run these two and compare:

openclaw agent --agent main --local --message "hi" --json
openclaw agent --agent coder --local --message "hi" --json

If main --local works but coder --local fails, that strongly points to the coder agent’s workspace/state, not OpenRouter or TUI.

First thing I’d inspect

#

The broken agent’s workspace files, especially:

  • BOOTSTRAP.md
  • AGENTS.md
  • SOUL.md

BOOTSTRAP.md is only meant for brand new workspaces and should not stick around after first-run. If the new agents still have a leftover BOOTSTRAP.md, that’s suspicious.

So I’d check:

  1. openclaw agents list to find the broken agent’s workspace
  2. compare that workspace against main
  3. if BOOTSTRAP.md exists in the broken agent workspace, move/delete it and retry

If you paste:

  • openclaw agents list
  • both --local command outputs