401 authentication

[little pier]

I am setting up openclaw on a linux machine with a setup_token. I am getting a 401 authentication error. Where should I paste the correct token?

openclaw models auth setup-token --provider anthropic

⠋ sending 0s | connected
agent main | session main (openclaw-tui) | anthropic/claude-sonnet-4-6 | think
low | tokens ?/200k
⠋ dillydallying… • 0s | connected
run error: HTTP 401 authentication_error: Invalid bearer token (request_id:
req_011CYYxixWhUAbdWFosSfsZm) ────────────
connected | error
agent main | session main (openclaw-tui) | anthropic/claude-sonnet-4-6 | think
low | tokens ?/200k

[polar locust]

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

[spark oracle]

That 401 is coming from Anthropic, and it usually means OpenClaw is holding the wrong token (often people accidentally paste the OpenClaw gateway/dashboard token instead of an Anthropic one).

For Claude subscription auth, you need an Anthropic setup-token generated by the Claude Code CLI:

1. Generate a fresh setup-token (can be on any machine):

claude setup-token

2. Paste it on the machine that runs the OpenClaw Gateway (that’s where the auth store lives):

openclaw models auth paste-token --provider anthropic

…and paste the token when prompted.

Alternative: openclaw onboard → pick “Anthropic token (paste setup-token)”.

3. Verify OpenClaw sees it:

openclaw models status

If you already ran openclaw models auth setup-token --provider anthropic, but it still 401s, the token you used is almost certainly stale/revoked → re-run claude setup-token and paste again.

Two quick questions to pinpoint where it needs to be pasted:

• What does openclaw --version show?
• Is your Gateway running on this same Linux box, or are you in remote mode (CLI on laptop → Gateway on server)?

[little pier]

Hm, I recreated the setup-token and pasted it properly when prompted. I've pasted it once again and this is the output that I get.

🦞 OpenClaw 2026.2.26 (bc50708)
I can run local, remote, or purely on vibes—results may vary with DNS.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-sonnet-4-6
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

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

• anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=3 (oauth=0, token=3, api_key=0) | anthropic:default=token:sk-ant-o...5fojvyu0, anthropic:manual=token:sk-ant-o...6pFvZMgL, anthropic:claude=token:sk-ant-o...6pFvZMgL

OAuth/token status

• anthropic
  • anthropic:claude static
  • anthropic:default static
  • anthropic:manual static

If this is correct, how can I start with hatching the bot without going through the whole onboarding process again?

[spark oracle]

Your models status output looks like the token(s) are stored correctly — you now have 3 Anthropic token profiles:

• anthropic:default (token A)
• anthropic:manual (token B)
• anthropic:claude (token B)

The important bit: OpenClaw often does not automatically “fail over” to the next profile on a 401. So if it tries anthropic:default first and that one is stale, you’ll keep getting “Invalid bearer token” even though you pasted a fresh one (which likely ended up in anthropic:claude).

Fix: force OpenClaw to use the good profile

On the gateway host, run:

openclaw models auth order set --provider anthropic anthropic:claude
openclaw gateway restart

(That pins Anthropic auth to anthropic:claude for the agent.)

Docs: https://docs.openclaw.ai/gateway/authentication#controlling-which-credential-is-used

Quick way to confirm which profile is failing (optional but useful)

This will probe Anthropic live and tell you exactly which profile 401s:

openclaw models status --probe --probe-provider anthropic

About “hatching” without re-onboarding

You don’t need to rerun onboarding. Once auth is fixed, just restart the gateway (openclaw gateway restart) and then open the TUI / send a message again — that’s effectively the “hatch”.

If anthropic:claude still 401s even after the order change, paste the output of openclaw models status --probe --probe-provider anthropic (it redacts tokens) and we can see which profile Anthropic is rejecting.

[little pier]

how do I open the TUI?

[spark oracle]

To open the Terminal UI:

1. Make sure the Gateway is running (either foreground or daemon):

openclaw gateway status
# if not running:
openclaw gateway start # daemon
# or: openclaw gateway # foreground (in a terminal)

2. Start the TUI:

openclaw tui

If your Gateway is on a different machine (or requires explicit auth), use:

openclaw tui --url ws://<gateway-host>:18789 --token <GATEWAY_TOKEN>

Important: that --token is the OpenClaw gateway auth token (gateway.auth.token), not your Anthropic setup-token.

TUI docs/examples: https://docs.openclaw.ai/web/tui

[little pier]

Hm, I'm confused, I'm still getting the token bearer problem. Didn't the token store correctly previously? Perhaps it stored correctly, but is it even the RIGHT token?

Wake up, my friend

run error: HTTP 401 authentication_error: Invalid bearer token (request_id:
req_011CYZ2BwBvzSSGRsfqzP1VU)

Gateway status

Link channel: unknown

Heartbeat: 1h (main)

Session store: /home/yazzbert/.openclaw/agents/main/sessions/sessions.json

Default model: claude-sonnet-4-6 (200k ctx)

Active sessions: 1

Recent sessions:

• agent:main:main [direct] | 1m ago | model claude-sonnet-4-6 | tokens ?/200k
  | flags: system, id:5e4b00b4-7a1f-4374-bf39-417e37360197
  connected | error
  agent main | session main (openclaw-tui) | anthropic/claude-sonnet-4-6 | think
  low | tokens ?/200k
  ────────────────────────────────────────────────────────────────────────────────

────────

[spark oracle]

Yeah — your token did store correctly (you can see 3 Anthropic token profiles in auth-profiles.json). The problem now is: which one is OpenClaw actually using, and is any of them valid with Anthropic.

1) Don’t paste tokens in Discord

(Just saying because the next commands will help without sharing secrets.)

2) Run a live probe to see which profile(s) are valid

On the gateway host, run:

openclaw models status --probe --probe-provider anthropic \
--probe-profile anthropic:default \
--probe-profile anthropic:claude \
--probe-profile anthropic:manual

That should tell you which profile is returning the 401.

3) If one profile probes OK: force OpenClaw to use it

Example (if anthropic:claude is the good one):

openclaw models auth order set --provider anthropic anthropic:claude
openclaw gateway restart

(Then retry in the TUI.)

Docs for auth order: https://docs.openclaw.ai/gateway/authentication#controlling-which-credential-is-used

4) If all profiles 401: it’s the wrong kind of token (for OpenClaw)

In that case your “setup-token” isn’t being accepted for general Anthropic API requests on your account (this happens for some Claude credentials). The reliable fix is: use an Anthropic API key instead (recommended by the docs):

• create key in Anthropic Console
• put it on the gateway host (for daemon use, best place is ~/.openclaw/.env)

• restart gateway

Docs: https://docs.openclaw.ai/gateway/authentication#recommended-anthropic-setup-api-key

If you paste the output of the --probe command (it doesn’t reveal the token), I can tell you exactly which branch you’re in.

[little pier]

OAuth/token status

• anthropic
  • anthropic:claude static
  • anthropic:default static
  • anthropic:manual static

Auth probes
┌──────────────────┬────────────────────────┬─────────────────────────────────┐
│ Model │ Profile │ Status │
├──────────────────┼────────────────────────┼─────────────────────────────────┤
│ anthropic/ │ anthropic:claude │ ok · 1.5s │
│ claude-sonnet-4- │ (token) │ │
│ 6 │ │ │
│ anthropic/ │ anthropic:default │ unknown · - │
│ claude-sonnet-4- │ (token) │ ↳ Excluded by auth.order for │
│ 6 │ │ this provider. │
│ anthropic/ │ anthropic:manual │ unknown · - │
│ claude-sonnet-4- │ (token) │ ↳ Excluded by auth.order for │
│ 6 │ │ this provider. │
└──────────────────┴────────────────────────┴─────────────────────────────────┘
Probed 1 target in 1.5s

It looks like one is good. Can I delete the others somehow?

[spark oracle]

Nice — that probe result means anthropic:claude is valid and the 401 should be gone as long as OpenClaw is actually using that profile.

Do you need to delete the other profiles?

No. The clean/normal way is exactly what you’ve already done: pin the provider auth order so only the good one is used:

openclaw models auth order set --provider anthropic anthropic:claude

(OpenClaw will just ignore the others.)

If you really want to remove them

There isn’t a documented openclaw models auth remove … command right now (CLI only supports add/setup-token/paste-token + auth order …).

So deletion is manual:

1. Stop the gateway (so nothing is writing the file while you edit):

openclaw gateway stop

2. Backup + edit:

• File: ~/.openclaw/agents/main/agent/auth-profiles.json
• Make a backup first:

cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.json.bak

• Open it in an editor and remove the entries for anthropic:default and anthropic:manual (leave anthropic:claude).

3. Start again + re-check:

openclaw gateway start
openclaw models status --probe --probe-provider anthropic

Quick sanity check in the TUI (optional)

In the TUI you can also pin the session explicitly:

• /model anthropic/claude-sonnet-4-6@anthropic:claude

If you send a new message in the TUI now, does it still 401, or does it reply?

[little pier]

Okay, i didn't delete it but it's so strange:

yazzbert@openclaw:~$ openclaw gateway

🦞 OpenClaw 2026.2.26 (bc50708) Siri's competent cousin.

18:37:10 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /home/yazzbert/.openclaw/canvas)
18:37:10 [heartbeat] started
18:37:10 [health-monitor] started (interval: 300s, grace: 60s)
18:37:10 [gateway] agent model: anthropic/claude-sonnet-4-6
18:37:10 [gateway] listening on ws://127.0.0.1:18789, ws://[::1]:18789 (PID 37490)
18:37:10 [gateway] log file: /tmp/openclaw/openclaw-2026-02-27.log
18:37:10 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
18:37:10 [hooks:loader] Registered hook: boot-md -> gateway:startup
18:37:10 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
18:37:10 [hooks:loader] Registered hook: command-logger -> command
18:37:10 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
18:37:10 [hooks] loaded 4 internal hook handlers
18:37:10 [telegram] [default] starting provider (@little pier_bot)
18:37:10 [telegram] autoSelectFamily=true (default-node22)
18:37:10 [telegram] global undici dispatcher autoSelectFamily=true
18:37:10 [telegram] dnsResultOrder=ipv4first (default-node22)

but i still get the 401 error.

[spark oracle]

If models status --probe says anthropic:claude = ok, then the token itself is fine.

So if you still see HTTP 401 … Invalid bearer token during a run, it almost always means the run is not actually using that profile (most commonly: the session is pinned to a different profile from earlier troubleshooting).

Check + fix inside the TUI

In the TUI, run:

1. See what the session is using:

/model status

2. Force-pin the session to the working profile:

/model anthropic/claude-sonnet-4-6@anthropic:claude

3. Start a fresh session (so no old pins/overrides linger):

/new

Then send a normal message again.

Also verify the per-agent order (outside TUI)

On the gateway host:

openclaw models auth order get --provider anthropic

It should show anthropic:claude first (or as the only entry).

If it STILL 401s after that

Tail the gateway log and paste the few lines around the error (it’ll be redacted, no secrets):

openclaw logs --follow

That log usually reveals which profileId it tried for the Anthropic request, which will confirm whether it’s a session pin vs something else.

[little pier]

Still 401ing
18:43:30 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=3ea4a96b-4177-4655-b40e-cda39190ef56 totalActive=1
18:43:30 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=041ed930-f068-47d4-a1ae-76ce4c234e2d sessionId=3ea4a96b-4177-4655-b40e-cda39190ef56
18:43:30 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=041ed930-f068-47d4-a1ae-76ce4c234e2d
18:43:31 warn agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=041ed930-f068-47d4-a1ae-76ce4c234e2d isError=true error=HTTP 401 authentication_error: Invalid bearer token (request_id: req_011CYZ4qVvwTPY9s2d2QgYWY)
18:43:31 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=041ed930-f068-47d4-a1ae-76ce4c234e2d sessionId=3ea4a96b-4177-4655-b40e-cda39190ef56 durationMs=221
18:43:31 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=3ea4a96b-4177-4655-b40e-cda39190ef56 totalActive=0
18:43:31 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=041ed930-f068-47d4-a1ae-76ce4c234e2d sessionId=3ea4a96b-4177-4655-b40e-cda39190ef56 durationMs=257 aborted=false
18:43:31 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=260 active=0 queued=0
18:43:31 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=263 active=0 queued=0
18:43:48 info Agent: main
18:43:48 info Provider: anthropic
18:43:48 info Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json
18:43:48 info Order override: anthropic:claude

[spark oracle]

That log line at the end is the key:

• your CLI probe shows anthropic:claude is OK
• but the running Gateway process is still sending a request that Anthropic rejects with “Invalid bearer token”

The most common reason: the Gateway you’re currently running hasn’t reloaded the updated auth profiles (the CLI reads the file on disk; the Gateway may have the old token snapshot in memory until restart).

Do this (in this order)

1. Fully restart the Gateway (since you’re running it in the foreground):

• go to the terminal where openclaw gateway is running
• press Ctrl+C
• start it again:

openclaw gateway

(If you were running it as a service instead: openclaw gateway restart.)

2. Open the TUI in a fresh session (avoids any old per-session model/profile pin):

openclaw tui --session hatch2

3. In the TUI, explicitly pin the working profile for this session:

/model anthropic/claude-sonnet-4-6@anthropic:claude

4. Send a message.

If it still 401s after the gateway restart

Run this and paste the output (no secrets):

openclaw models auth order get --provider anthropic

openclaw models status --probe --probe-provider anthropic

That will confirm whether the restarted Gateway is actually seeing the same auth-profiles.json state the CLI is probing.

[little pier]

I manually changed that one file to delete the other two tokens. Still 401'ing...

yazzbert@openclaw:~$ openclaw models status --probe --probe-provider anthropic

🦞 OpenClaw 2026.2.26 (bc50708) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-sonnet-4-6
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

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

• anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | anthropic:claude=token:sk-ant-o...6pFvZMgL

OAuth/token status

• anthropic
  • anthropic:claude static

Auth probes
┌─────────────────────────────┬──────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├─────────────────────────────┼──────────────────────────┼────────────┤
│ anthropic/claude-sonnet-4-6 │ anthropic:claude (token) │ ok · 1.4s │
└─────────────────────────────┴──────────────────────────┴────────────┘
Probed 1 target in 1.4s

I don't get it..

[spark oracle]

That is maddening — because your probe proves the credential itself is valid:

• anthropic:claude probes OK
• but your actual run still gets HTTP 401 … Invalid bearer token

When that happens, it usually means the run is not using the same effective auth context the probe is using (session pin / model pin / or you’re hitting a different gateway process than you think).

Let’s nail it down with two quick checks.

1) In the TUI: show what the session is actually using

Run these in the TUI and paste the output:

/model status

Then do a totally clean session + explicit pin:

/new
/think off
/model anthropic/claude-sonnet-4-6@anthropic:claude

Send a simple “hi”.

If that still 401s, it’s no longer a “wrong profile” issue.

2) Confirm there isn’t another Gateway running somewhere

From a normal shell (not TUI), run:

openclaw gateway status

(If it shows a running service while you also run openclaw gateway in a terminal, you might be talking to the “other” one.)

If it still 401s after /think off + explicit @anthropic:claude

At that point it smells like a bug in 2026.2.26 where the gateway run path is not using the same token that probes are using (or it’s mangling it).

Best next artifact to share (safe, tokens redacted) is:

openclaw status --all

and the last ~30 lines around the 401 from:

openclaw logs --follow

Paste those and we can tell whether the gateway is actually selecting anthropic:claude for the failing request (and if it is, you’ve got a clean repro to file as a GitHub issue).

[little pier]

Is it possible that the auth token simply doesn't work?

I have a Claude Code Max subscription as an individual.

[spark oracle]

It can happen in general that a Claude/Claude Code credential doesn’t work for “normal” Anthropic API calls — but in your case, it’s not that.

You’ve proven the token works with OpenClaw:

• openclaw models status --probe --probe-provider anthropic → anthropic:claude … ok

So your Claude Code Max individual subscription + setup-token is fine, and OpenClaw can successfully call Anthropic with that profile.

What’s broken is: the Gateway run path is still using a different auth context than the probe (most often because you’re accidentally running against a different OpenClaw state dir/profile, or a different gateway process, or the gateway hasn’t picked up the new auth snapshot).

The two checks that usually reveal it

1. Are you accidentally using a different profile/state dir somewhere?
   Have you ever run OpenClaw with --dev or --profile <name>? That creates a different ~/.openclaw-*/ directory with its own auth store.

Run and paste the output:

openclaw gateway status

(It prints which config/state it’s actually using.)

2. Make sure you restart the gateway that your TUI is connected to
   After editing auth-profiles.json, the gateway won’t hot-reload it.

If you’re using the daemon:

openclaw gateway restart

If you’re running openclaw gateway in the foreground: stop it (Ctrl+C) and start it again.

One more super-targeted TUI check

In the TUI, paste:

/model status

That will show whether the session is pinned to some old/invalid profile.

If you share openclaw gateway status + the TUI /model status, we can point to the exact mismatch (wrong state dir vs wrong session pin vs wrong gateway).

[little pier]

Okay, I got it up and running. I think Anthropic banned Subscriptions. Anyways, I got an API key and everything is functioning. I'm getting this error though:
run error: The AI service is temporarily overloaded. Please try again in a moment.

What is happening exactly?

[spark oracle]

That message is coming from Anthropic, not OpenClaw.

It typically corresponds to Anthropic’s “overloaded” / temporary capacity condition (often HTTP 529 on their side): their servers are busy, so they reject the request even though your API key is valid. It’s transient — not a ban, and not “bad token”.

What you can do:

• Retry after ~10–60s (Anthropic load tends to come in waves).
• Reduce burstiness (don’t send multiple messages quickly / avoid high concurrency).
• Add model/provider fallbacks so OpenClaw can keep replying when Anthropic is overloaded. See: https://docs.openclaw.ai/concepts/model-failover
  (You can manage fallbacks via openclaw models fallbacks … or config.)
• If you want to confirm the exact status code/type Anthropic returned, tail logs:

openclaw logs --follow

You should see a 529/overloaded-style error near the failure.

If your original 401 is fully resolved now, please also mark the solution message (right‑click → Apps → ✅ Mark Solution) so Answer Overflow indexes it for the next person.

[little pier]

Alright, anthropic banned subscriptions, that's why. I got an API key and now we're in business.

How do I switch models to the latest /highest end claude model?

[spark oracle]

To switch to the “latest / highest-end” Claude model, don’t guess the model ID — have OpenClaw show you what your current install/provider exposes, then select it.

In chat / TUI (quickest)

• Open the model picker:
• TUI: press Ctrl+L (model picker), or run:

/model
/model list

• Discord: run /model (interactive picker)

Pick the most capable Claude entry in that list (usually the Opus-tier one), submit, then retry your message.

From the shell (set the default for the agent)

1. List available Anthropic models:

openclaw models list --all --provider anthropic

2. Set the one you want as the default:

openclaw models set anthropic/<model-id-from-the-list>

3. Verify:

openclaw models status

Docs:

• Models / switching: https://docs.openclaw.ai/concepts/models
• Anthropic provider notes: https://docs.openclaw.ai/providers/anthropic

If you tell me which UI you’re using most (Discord vs TUI vs Control UI), I can give the shortest exact clicks/commands for that path.

[little pier]

How can I paste something into the TUI? If I try to copy/paste it just says "past #3: +15 lines"

[spark oracle]

That’s actually normal in the OpenClaw TUI.

When you paste something that’s multi‑line / “large”, the TUI doesn’t inline all the lines into the editor (it would be slow + messy). Instead it inserts a paste marker like:

• paste #3: +15 lines

…and it keeps the real pasted text in an internal buffer. When you press Enter to submit/send, the TUI will expand that marker back into the full pasted content before sending it to the Gateway.

A couple practical tips:

• If you just need to paste a single line (e.g. /model …), it should paste normally.
• If you need to paste multi-line but also edit it, it’s usually easier to edit in your local editor first, then paste the final version.

Also: avoid pasting secrets into chat (API keys, tokens).

[little pier]

Thanks, i understand. I chose a new model but it still seems to keep "claude-sonnet-4-6". I stopped the gateway and started it again, how can I force the model to actually change...?

20:54:22 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /home/yazzbert/.openclaw/canvas)
20:54:22 [heartbeat] started
20:54:22 [health-monitor] started (interval: 300s, grace: 60s)
20:54:22 [gateway] agent model: anthropic/claude-opus-4-6
20:54:22 [gateway] listening on ws://127.0.0.1:18789, ws://[::1]:18789 (PID 10329)
20:54:22 [gateway] log file: /tmp/openclaw/openclaw-2026-02-27.log
20:54:22 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
20:54:23 [hooks:loader] Registered hook: boot-md -> gateway:startup
20:54:23 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
20:54:23 [hooks:loader] Registered hook: command-logger -> command
20:54:23 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
20:54:23 [hooks] loaded 4 internal hook handlers
20:54:23 [telegram] [default] starting provider (@little pier_bot)
20:54:23 [telegram] autoSelectFamily=true (default-node22)
20:54:23 [telegram] global undici dispatcher autoSelectFamily=true
20:54:23 [telegram] dnsResultOrder=ipv4first (default-node22)

model set to anthropic/claude-opus-4-6
connected | idle
agent main | session main (openclaw-tui) | anthropic/claude-sonnet-4-6 | think low | tokens 19k/200k (9%)

[spark oracle]

Your Gateway did pick up the new default — the log proves it:

[gateway] agent model: anthropic/claude-opus-4-6

What’s happening is the session main in the TUI is still pinned to the old model (or the TUI footer is showing stale session state).

Do this in the TUI:

1. Confirm what the session thinks it’s using:

/model status

2. Reset the session so it re-inherits the agent default model:

/new

3. (Optional) Explicitly pin Opus for this session:

/model anthropic/claude-opus-4-6

If after that the footer still shows Sonnet, it’s just the TUI display being stale — quickest fix is to restart the TUI:

/exit

then run openclaw tui again (or start a fresh session name like openclaw tui --session opus).

Once you send the next message, it should run on Opus.

[little pier]

Alright. My ssh connection was severed. How can I restart the conversation and pick up where i left off?

[spark oracle]

If the Gateway was still running, you didn’t lose the conversation — the session lives on the gateway (in ~/.openclaw/agents/main/sessions/…), not in your SSH terminal.

1) Reconnect + make sure the Gateway is up

openclaw gateway status

If it’s not running, start it again (daemon):

openclaw gateway start

(or foreground: openclaw gateway)

2) Re-open the TUI on the same session

Most likely you were using session main, so:

openclaw tui --session main