#reset

1 messages · Page 1 of 1 (latest)

raven prairieBOT
restive lichenBOT
#

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

raven prairieBOT
indigo canyonBOT
#

First, paste openclaw --version so I can match your build.

Short version, there are 2 different resets:

  • /reset or /new = fresh chat session
  • BOOTSTRAP.md again = fresh workspace

So if you want to start from BOOTSTRAP.md like the very beginning, /reset is not enough. BOOTSTRAP.md is only created for a brand-new workspace.

Safest path:

openclaw backup create
openclaw reset --dry-run
openclaw reset --scope full
openclaw setup
tacit eagle
#

ok i reran the setup command

indigo canyonBOT
#

Got it. If you reran openclaw setup on the same existing workspace, BOOTSTRAP.md usually will not come back. It is meant for a brand-new workspace.

So your next step is one of these:

Option 1, safest, recommended
Use a new empty workspace:

openclaw setup --workspace ~/.openclaw/workspace-fresh
openclaw gateway restart

That should give you a fresh workspace and the bootstrap flow again.

Option 2, full wipe
If you want everything reset exactly like day 1:

tacit eagle
#

delete workspace

indigo canyonBOT
#

Yep, if your goal is to trigger first-run bootstrap again, the workspace is the thing to replace.

I would not hard-delete it though. Safer:

  1. Check the active workspace:
    openclaw config get agents.defaults.workspace
    
  2. Move that folder to Trash or rename it in your file manager
  3. Run:
    openclaw setup
    openclaw gateway restart
    

That should recreate a brand-new workspace and give you BOOTSTRAP.md again.

tacit eagle
#

Wrote ~/.openclaw/openclaw.json
Workspace OK: ~/.openclaw/workspace
Sessions OK: ~/.openclaw/agents/main/sessions
chotumiya@chotus-Mac-mini /Users % openclaw gateway restart

🦞 OpenClaw 2026.4.18 (0195da6) — I don't judge, but your missing API keys are absolutely judging you.

Gateway LaunchAgent was installed but not loaded; re-bootstrapped launchd service.
chotumiya@chotus-Mac-mini /Users %

indigo canyonBOT
#

Nice, version looks fine. The important bit is this line:

Workspace OK: ~/.openclaw/workspace

That means setup reused the existing workspace, so it probably did not recreate BOOTSTRAP.md.

Best next step, without deleting anything:

openclaw setup --workspace ~/.openclaw/workspace-fresh
openclaw gateway restart

That points OpenClaw at a brand-new empty workspace, which is the cleanest way to get the bootstrap flow again.

The API key joke in the output is unrelated 😄

tacit eagle
#

i use this openclaw reset --scope full

indigo canyonBOT
#

Yep, that is the full wipe option.

It removes:

  • config
  • creds/auth
  • sessions
  • workspace

So if your goal is true first-run state, that’s the right one.

After it finishes, run:

openclaw setup

or

#
openclaw onboard

Then start/restart the gateway:

openclaw gateway restart

At that point, BOOTSTRAP.md should be back in the fresh workspace.

If you want, paste the output after openclaw reset --scope full and I’ll sanity-check the next step.

tacit eagle
#

thankyou

indigo canyonBOT
#

You’re welcome, glad we got it sorted 🦐

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future folks.

indigo canyonBOT
#

Ah, yep, this one is simple: your shell is still sitting inside a folder that was already deleted.

That’s what this means:

  • getcwd: cannot access parent directories
  • process.cwd failed
  • uv_cwd

So first move to a real directory, then rerun the command:

cd ~
pwd
openclaw reset --scope full

After that:

#
openclaw setup
openclaw gateway restart

Important: if you’re using openclaw reset --scope full, you do not need to manually delete the workspace first. Let reset handle it.

If you want, paste the next output after cd ~ and rerunning it.

tacit eagle
#

trying to enable compaction memory flush and session memory but bot gave thisI'm stuck — I need to run openclaw config set commands to enable memory features, but I don't have a shell/exec tool available in this session. Earlier I somehow ran openclaw gateway status and openclaw config set — were those using a different channel?
Can you help me figure out how to run CLI commands here? Or point me at the memory config settings so I can tell you what to set manually?

indigo canyonBOT
#

Yeah, those earlier openclaw ... commands were not coming from this Discord help thread. This thread can’t run shell commands on your Mac.

So you have 2 real options:

  1. run the CLI in your local terminal
  2. edit ~/.openclaw/openclaw.json manually

Also, these memory features are different things:

  • Compaction memory flush: agents.defaults.compaction.memoryFlush
    • already enabled by default
  • Session memory hook: bundled hook named session-memory
    • saves recent chat to memory/YYYY-MM-DD-slug.md on /new or /reset
  • Session transcript search: agents.defaults.memorySearch.experimental.sessionMemory
    • this is optional and separate

If you want the manual config route, this is the relevant JSON5:

#
{
  agents: {
    defaults: {
      compaction: {
        memoryFlush: {
          enabled: true
        }
      },
      memorySearch: {
        experimental: {
          sessionMemory: true
        },
        sources: ["memory", "sessions"]
      }
    }
#
  },
  hooks: {
    internal: {
      entries: {
        "session-memory": {
          enabled: true
        }
      }
    }
  }
}

Then restart:

#
openclaw gateway restart

If you only want memory flush + session-memory hook, and not transcript search, you can skip the memorySearch block entirely.

CLI bits that are definitely valid:

openclaw hooks enable session-memory
openclaw gateway restart

Docs:

#

If you want, paste your current openclaw.json and I’ll mark exactly what to add.

tacit eagle
#

why cant the bot do it

indigo canyonBOT
#

Because this bot is in the public support Discord, not on your Mac.

So from here I can:

  • explain the config
  • point you to docs
  • sanity-check your commands/output

But I cannot:

  • run openclaw on your machine
  • edit ~/.openclaw/openclaw.json
  • use your local shell unless your own OpenClaw session exposes exec

If it worked somewhere else before, that was probably:

  • your local terminal, or
  • a different OpenClaw session/channel where exec was enabled

So the short answer is: wrong surface, no machine access. If you want, I can still walk you through the exact commands step by step.

tacit eagle
#

no my openclaw bot

#

i mean agent

#

""I'm stuck — I need to run openclaw config set commands to enable memory features, but I don't have a shell/exec tool available in this session. Earlier I somehow ran openclaw gateway status and openclaw config set — were those using a different channel?
Can you help me figure out how to run CLI commands here? Or point me at the memory config settings so I can tell you what to set manually? "" this agent response

indigo canyonBOT
#

Ah, gotcha, your own OpenClaw bot.

In that case, the usual reason is tool policy. Your bot can only run shell commands if that session is allowed to use exec.

Most common blockers:

  • tools.profile is minimal or messaging
    • those do not include exec
  • tools.allow / tools.deny removed exec
  • channel/provider-specific tool policy is tighter than the global one
  • exec approvals/security are blocking host execution

The important doc bit is:

  • exec lives in group:runtime
  • tools.profile: "coding" includes group:runtime
#

So the simplest baseline is:

{
  tools: {
    profile: "coding"
  }
}

Then restart the gateway.

If you want to inspect it first, check:

openclaw config get tools.profile
#

Yep, for the agent too.

An agent can only do what its tool policy allows.
openclaw config set ... is a CLI command, so the agent needs the exec tool to run it.

So if the agent can’t do it, that usually means:

  • the agent/session does not have exec
  • or exec is blocked by tool policy / channel policy
  • or approvals/security are stopping host shell access

That’s why it can still chat and explain, but not actually run:

openclaw config set ...
openclaw gateway restart
#

If you want the agent to be able to do that, the usual baseline is:

{
  tools: {
    profile: "coding"
  }
}

because coding includes group:runtime, which includes exec.

If you paste your agent/tool config, I can point to the exact blocker.

#

Yep, that response is basically the smoking gun.

It means the agent looked at its current tool surface and does not see exec in this session.

So the agent is not being weird, it is telling you:

  • “I can chat”
  • “I can maybe read/write files”
  • “but I cannot run shell commands like openclaw config set ... from here”

And yes, earlier commands could absolutely have been from a different session/surface. Tool access can differ by:

  • agent
  • channel/provider
  • tool policy
  • session/runtime mode
#

So the real issue is still: this session does not have exec.

If you want the agent to do CLI work, check the config that controls tool access:

openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get tools.byProvider

If you paste those, I can tell you exactly why this agent session lost shell access.

#

Found it. This is exactly why the agent can’t do it.

What your config is doing

  • tools.profile = messaging
    • that profile is chat-only
  • tools.deny includes:
    • group:runtime → blocks exec
    • group:fs → blocks read/write/edit

So the agent is locked out of both:

  • running openclaw config set ...
  • editing config files directly

Also, this part is not the main issue:

#
{
  "security": "deny",
  "ask": "always"
}

That only matters after exec is allowed. Right now group:runtime is denied first, so the agent never even gets that far.

Short version

Your agent cannot do it because your config explicitly says:

messaging only, and no runtime/filesystem tools

If you want the agent to be able to do this

#

Best fix:

  • change profile to coding
  • remove group:runtime and group:fs from tools.deny
  • restart gateway

For example, at minimum:

openclaw config set tools.profile coding

Then edit tools.deny so it no longer contains:

"group:runtime",
"group:fs"
#

Then:

openclaw gateway restart

If you want, paste your ~/.openclaw/openclaw.json and I’ll show the exact lines to change.

tacit eagle
#

The hardened config blocks exec by default (security: deny). To enable memory features, you'll need to run these commands yourself:
Copy
openclaw config set memory.compaction.flushEnabled true
openclaw config set memory.session.enabled true
Or I can temporarily lower exec security if you want me to do it. Your call.

indigo canyonBOT
#

Yeah, that agent reply is wrong on two points.

1) The blocker is not tools.exec.security: deny

exec is blocked earlier by your tool policy:

  • tools.profile: messaging
  • tools.deny contains group:runtime

So lowering exec security would not fix the real problem.

2) Those config keys are not real

These are wrong:

openclaw config set memory.compaction.flushEnabled true
openclaw config set memory.session.enabled true
#

The verified settings are:

Compaction memory flush

openclaw config set agents.defaults.compaction.memoryFlush.enabled true

Session memory hook

openclaw hooks enable session-memory

If you meant session transcript search instead, that is:

openclaw config set agents.defaults.memorySearch.experimental.sessionMemory true
#
openclaw config set agents.defaults.memorySearch.sources '["memory","sessions"]' --strict-json

So the clean path is:

  1. fix tool policy if you want the agent to do shell work
  2. otherwise run the correct commands manually

Docs:

If you want, I can give you the exact 3-command sequence for your case only.

tacit eagle
#

fix policy

#

fix

indigo canyonBOT
#

Yep. Here’s the fix.

1) Let the agent use shell + file tools again

This keeps approvals on, so it is not YOLO mode:

openclaw config set tools.profile coding
openclaw config set tools.deny '["group:automation","sessions_spawn","sessions_send"]' --strict-json
openclaw config set tools.exec.security allowlist
openclaw config set tools.exec.ask on-miss
openclaw gateway restart

After that, start a fresh chat/session with the agent (/new is fine).

2) Enable the memory features you were asking about

#

Session memory hook

openclaw hooks enable session-memory

Compaction memory flush
(this is already on by default, but you can force it explicitly)

openclaw config set agents.defaults.compaction.memoryFlush.enabled true

Optional: session transcript search

openclaw config set agents.defaults.memorySearch.experimental.sessionMemory true
openclaw config set agents.defaults.memorySearch.sources '["memory","sessions"]' --strict-json
openclaw gateway restart
#

Why this fixes it

Your current config had:

  • tools.profile = messaging
  • tools.deny blocking group:runtime and group:fs

So the agent literally had no exec, read, write, or edit.

If you want, paste the output after running step 1 and I’ll verify it before you try the agent again.

#

No worries, this just means tools.exec.security got written in a bad shape. Let’s rewrite it cleanly.

Run these exactly:

openclaw config set tools.profile '"coding"' --strict-json
openclaw config set tools.deny '["group:automation","sessions_spawn","sessions_send"]' --strict-json
openclaw config unset tools.exec
openclaw config set tools.exec '{"security":"allowlist","ask":"on-miss","pathPrepend":["/Users/chotumiya/.local/bin"]}' --strict-json
openclaw config validate

If validation passes, then:

openclaw gateway restart
#

Then you can enable the memory pieces:

openclaw hooks enable session-memory
openclaw config set agents.defaults.compaction.memoryFlush.enabled true

Optional transcript search:

openclaw config set agents.defaults.memorySearch.experimental.sessionMemory true
openclaw config set agents.defaults.memorySearch.sources '["memory","sessions"]' --strict-json
openclaw gateway restart

So, skip doctor for the moment. First get openclaw config validate clean. If you want, paste the validate output next and I’ll check it.

tacit eagle
#

chotumiya@chotus-Mac-mini ~ % openclaw config set tools.deny '["group:automation","sessions_spawn","sessions_send"]' --strict-json
Invalid config at /Users/chotumiya/.openclaw/openclaw.json:\n- tools.exec.security: Invalid option: expected one of "deny"|"allowlist"|"full"

🦞 OpenClaw 2026.4.19-beta.1 (a56aa6c) — I'm like tmux: confusing at first, then suddenly you can't live without me.

Config invalid
File: ~/.openclaw/openclaw.json
Problem:

  • tools.exec.security: Invalid option: expected one of "deny"|"allowlist"|"full"

Run: openclaw doctor --fix
chotumiya@chotus-Mac-mini ~ % openclaw config unset tools.exec
Invalid config at /Users/chotumiya/.openclaw/openclaw.json:\n- tools.exec.security: Invalid option: expected one of "deny"|"allowlist"|"full"

🦞 OpenClaw 2026.4.19-beta.1 (a56aa6c) — Shell yeah—I'm here to pinch the toil and leave you the glory.

Config invalid
File: ~/.openclaw/openclaw.json
Problem:

  • tools.exec.security: Invalid option: expected one of "deny"|"allowlist"|"full"

Run: openclaw doctor --fix
chotumiya@chotus-Mac-mini ~ % openclaw doctor --fix

indigo canyonBOT
#

Yep, this part makes sense now.

Once openclaw.json is invalid, openclaw config set and config unset will refuse to touch it. So at this point the recovery path is:

  1. let openclaw doctor --fix finish
  2. if doctor does not repair it, manually fix the tools block in ~/.openclaw/openclaw.json

So right now, doctor is the correct move. 👍

If doctor asks to repair config, accept it.

If doctor fails to fix it

Open ~/.openclaw/openclaw.json in a text editor and make the tools section look like this:

tools: {
#
  profile: "coding",
  deny: ["group:automation", "sessions_spawn", "sessions_send"],
  exec: {
    security: "allowlist",
    ask: "on-miss",
    pathPrepend: ["/Users/chotumiya/.local/bin"]
  }
}

Then run:

openclaw config validate
openclaw gateway restart
#

After that:

openclaw hooks enable session-memory
openclaw config set agents.defaults.compaction.memoryFlush.enabled true

So for now, don’t fight config set anymore, wait for the doctor --fix result and paste the next output here.

tacit eagle
#

🦞 OpenClaw 2026.4.19-beta.1 (a56aa6c) — I'm the reason your shell history looks like a hacker-movie montage.

Config invalid at ~/.openclaw/openclaw.json:
× <root>: JSON5 parse failed: SyntaxError: JSON5: invalid character ',' at 78:4

Run openclaw doctor to repair, or fix the keys above manually.

indigo canyonBOT
#

Good, we’ve narrowed it down. This is now just a syntax error in openclaw.json, not a tool-policy mystery.

invalid character ',' at 78:4 usually means:

  • an extra comma
  • a missing } or ] right before that line
  • or a malformed block around line 78

Please run this read-only command and paste the output:

nl -ba ~/.openclaw/openclaw.json | sed -n '70,85p'

If you want a slightly wider view too:

#
nl -ba ~/.openclaw/openclaw.json | sed -n '60,95p'

Once I see that snippet, I can point to the exact character to delete/fix.

#

Thanks, that snippet itself actually looks mostly fine.

So the parser problem is probably a few lines earlier, where one of these happened:

  • missing {
  • extra }
  • missing , before the exec / elevated block
  • or the tools block got closed too early

Please paste just lines 55-79 too:

nl -ba ~/.openclaw/openclaw.json | sed -n '55,79p'

That should show the exact broken opening/closing pair.

#

You do not need to paste the whole file, just that slice.

tacit eagle
#

chotumiya@chotus-Mac-mini ~ % nl -ba ~/.openclaw/openclaw.json | sed -n '55,79p'
55 ask: "on-miss",
56 pathPrepend: ["/Users/chotumiya/.local/bin"]
57 }
58 },
59 "fs": {
60 "workspaceOnly": true
61 },
62 "web": {
63 "search": {
64 "provider": "brave",
65 "enabled": true
66 }
67 },
68 "exec": {
69 "security": "allow",
70 "ask": "always",
71 "pathPrepend": [
72 "/Users/chotumiya/.local/bin"
73 ]
74 },
75 "elevated": {
76 "enabled": false
77 }
78 },
79 "auth": {

indigo canyonBOT
#

Found it. There are 2 problems in that snippet.

Problem 1

Line 58 is closing the object too early.

Problem 2

Line 69 is invalid:

"security": "allow"

allow is not a valid value. It must be one of:

  • "deny"
  • "allowlist"
  • "full"
#

Fix

Change this region so it behaves like:

      },
      fs: {
        workspaceOnly: true
      },
      web: {
        search: {
          provider: "brave",
          enabled: true
        }
      },
      exec: {
#
        security: "allowlist",
        ask: "always",
        pathPrepend: [
          "/Users/chotumiya/.local/bin"
        ]
      },
      elevated: {
        enabled: false
      }

Concretely

  • change line 57 from } to },
  • delete line 58
  • change line 69 from "allow" to "allowlist"
#

Then run:

openclaw config validate

If that passes:

openclaw gateway restart

Then we can finish the memory setup.

tacit eagle
#

🦞 OpenClaw 2026.4.19-beta.1 (a56aa6c) — I keep secrets like a vault... unless you print them in debug logs again.

Config invalid at ~/.openclaw/openclaw.json:
× <root>: JSON5 parse failed: SyntaxError: JSON5: invalid character ',' at 78:4

Run openclaw doctor to repair, or fix the keys above manually.
chotumiya@chotus-Mac-mini ~ % nl -ba ~/.openclaw/openclaw.json | sed -n '55,79p'
55 ask: "on-miss",
56 pathPrepend: ["/Users/chotumiya/.local/bin"]
57 }
58 },
59 "fs": {
60 "workspaceOnly": true
61 },
62 "web": {
63 "search": {
64 "provider": "brave",
65 "enabled": true
66 }
67 },
68 "exec": {
69 "security": "allowlist",
70 "ask": "always",
71 "pathPrepend": [
72 "/Users/chotumiya/.local/bin"
73 ]
74 },
75 "elevated": {
76 "enabled": false
77 }
78 },
79 "auth": {

indigo canyonBOT
#

You’re super close. The problem is still lines 57-58.

Right now you have two closers in a row:

57          }
58        },
59        "fs": {

That means the object is still being closed too early before "fs".

Make lines 55-59 look exactly like this

        ask: "on-miss",
#
        pathPrepend: ["/Users/chotumiya/.local/bin"]
      },
      "fs": {
        "workspaceOnly": true

So:

  • line 57 should be },
  • line 58 should be deleted entirely

After that, run:

openclaw config validate
#

You fixed the "allow""allowlist" part already, nice. Now it’s just that extra }/, combo.

tacit eagle
#

chotumiya@chotus-Mac-mini ~ % nl -ba ~/.openclaw/openclaw.json | sed -n '50,79p'
50 "tools": {
51 profile: "coding",
52 deny: ["group:automation", "sessions_spawn", "sessions_send"],
53 exec: {
54 security: "allowlist",
55 ask: "on-miss",
56 pathPrepend: ["/Users/chotumiya/.local/bin"]
57 }
58 },
59 "fs": {
60 "workspaceOnly": true
61 },
62 "web": {
63 "search": {
64 "provider": "brave",
65 "enabled": true
66 }
67 },
68 "exec": {
69 "security": "allowlist",
70 "ask": "always",
71 "pathPrepend": [
72 "/Users/chotumiya/.local/bin"
73 ]
74 },
75 "elevated": {
76 "enabled": false
77 }
78 },
79 "auth": {

indigo canyonBOT
#

Ah, there it is. You have two exec blocks inside tools.

The broken one is the first one:

53          exec: {
54               security: "allowlist",
55        ask: "on-miss",
56        pathPrepend: ["/Users/chotumiya/.local/bin"]
57          }
58        },

Then you already have a second valid exec block at 68-74.

Fix

Delete lines 53-58 completely.

#

Your tools block should then be:

"tools": {
  profile: "coding",
  deny: ["group:automation", "sessions_spawn", "sessions_send"],
  "fs": {
    "workspaceOnly": true
  },
  "web": {
    "search": {
      "provider": "brave",
      "enabled": true
    }
  },
  "exec": {
#
    "security": "allowlist",
    "ask": "always",
    "pathPrepend": [
      "/Users/chotumiya/.local/bin"
    ]
  },
  "elevated": {
    "enabled": false
  }
},

After deleting 53-58, run:

#
openclaw config validate

If it passes, then:

openclaw gateway restart

Then we can finish the memory setup.

tacit eagle
#

chotumiya@chotus-Mac-mini ~ % openclaw config set memory.compaction.flushEnabled true

🦞 OpenClaw 2026.4.19-beta.1 (a56aa6c) — I keep secrets like a vault... unless you print them in debug logs again.

Error: Config validation failed: memory: Unrecognized key: "compaction"
chotumiya@chotus-Mac-mini ~ %

indigo canyonBOT
#

Yep, that command is using the wrong config path.

memory.compaction.flushEnabled does not exist.

Use these instead:

Compaction memory flush

openclaw config set agents.defaults.compaction.memoryFlush.enabled true

Session memory hook

openclaw hooks enable session-memory

Optional, session transcript search

#
openclaw config set agents.defaults.memorySearch.experimental.sessionMemory true
openclaw config set agents.defaults.memorySearch.sources '["memory","sessions"]' --strict-json

Then restart:

openclaw gateway restart

So the good news is your config is parsing again, this is just a bad key now, not a broken file.

tacit eagle
#

The exec tool is blocked by pairing requirement. There's a pending approval waiting for you on the Control UI — can you check and approve it?
Once approved, I'll:
Enable exec permanently
Turn on audio transcription
Enable memory features
Go to the Control UI and look for a pairing/approval request.

indigo canyonBOT
#

Yep, that means the agent can see exec now, but actual host execution is still gated by an approval/pairing step.

So:

  • open the Control UI
  • look for the pending pairing / exec approval
  • approve it

One important note: you do not need to let it “enable exec permanently” in a wide-open way just to finish setup.

Safer is:

  • approve the current request
  • keep exec on approval-gated mode (allowlist + on-miss / always)

That gives you the features without turning the agent loose.

If you don’t see the request in Control UI, check:

#
openclaw devices list

because sometimes it is really a pending device scope/pairing approval rather than a normal exec prompt.

If you want, once you approve it, paste the next agent message here and I’ll sanity-check what it wants to change before you accept anything broad.

tacit eagle
#

what is control UI

indigo canyonBOT
#

The Control UI is just OpenClaw’s web dashboard/admin page.

On the same machine where your gateway is running, open:

http://127.0.0.1:18789/

If it asks for auth, use your gateway token or password.

So when your agent says “check the Control UI”, it means:

  • open that local web page in your browser
  • look for the pending approval/pairing request there

Docs: https://docs.openclaw.ai/web/dashboard

If 127.0.0.1:18789 doesn’t open, tell me what you see and I’ll help from there.

tacit eagle
#

i dont see any UI

indigo canyonBOT
#

No problem. Let’s check whether the dashboard is actually up, and what URL/port it is using.

Please run these and paste the output:

openclaw status
openclaw gateway status
openclaw dashboard

What I’m looking for:

  • whether the gateway is running
  • whether it is really on 127.0.0.1:18789 or a different port
  • whether openclaw dashboard prints the exact browser URL

If the gateway is healthy, openclaw dashboard should usually give you the right link directly.

tacit eagle
#

no i mean the pariing request how do i acceopt from cli

indigo canyonBOT
#

Yep, for a device pairing request you can accept it from CLI like this:

openclaw devices list
openclaw devices approve <requestId>

A couple gotchas:

  • openclaw devices approve --latest only shows the newest pending request, it does not approve it
  • if the device retried pairing, the old request can be superseded, so run devices list right before approving

So the flow is:

openclaw devices list
#
openclaw devices approve <the-exact-requestId-from-list>

If you want, paste the openclaw devices list output here and I’ll tell you which requestId to use.

tacit eagle
#

hi

indigo canyonBOT
#

hey, what do you want to tackle next?

tacit eagle
#

Restarted LaunchAgent: gui/501/ai.openclaw.gateway
Timed out after 60s waiting for gateway port 18789 to become healthy.
Gateway process is running but port 18789 is still free (startup hang/crash loop or very slow VM startup).
Service runtime: status=running, state=active, pid=46989
Gateway port 18789 status: free.
Gateway restart timed out after 60s waiting for health checks.
Tip: openclaw gateway status --deep
Tip: openclaw doctor
chotumiya@chotus-Mac-mini ~ % openclaw doctor

indigo canyonBOT
#

Yep, this means the LaunchAgent started, but the gateway never actually came up on port 18789.

So the next useful data is:

openclaw doctor
openclaw gateway status --deep

If those still don’t show the cause, grab the latest log too:

tail -n 200 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Paste those outputs here, especially:

#
  • any Config invalid
  • any bind/auth error
  • any stack trace near the end

That should tell us whether this is still config fallout or a startup crash.

#

Nice, this is much clearer now. The gateway is not starting because your config is missing gateway.mode.

Fix

Run:

openclaw config set gateway.mode local
openclaw gateway restart

If that still fails, do the heavier repair:

openclaw setup
openclaw gateway restart
#

That means the fix still has not actually been written. gateway.mode is still missing.

At this point, do this in order:

openclaw config get gateway.mode
openclaw setup
openclaw config get gateway.mode
openclaw gateway restart

What I expect:

  • first config get gateway.mode → probably “path not found”
  • openclaw setup → should restamp local gateway config
  • second config get gateway.mode → should print local
#

If the second config get gateway.mode still does not print local, paste that output and I’ll have you fix the gateway block directly.

tacit eagle
#

its set to local still not restarting

indigo canyonBOT
#

Interesting. If openclaw config get gateway.mode says local, but the service still claims it is missing, then the LaunchAgent is probably reading a different/stale config or startup path.

Please paste these:

openclaw config file
tail -n 80 ~/.openclaw/logs/gateway.err.log
tail -n 80 ~/.openclaw/logs/gateway-restart.log

That should tell us:

  • which config file the CLI is editing
  • what the LaunchAgent is actually trying to start
  • whether the service is stuck on an old config snapshot or old command path

At this point I’m less worried about gateway.mode itself, and more about the service reading the wrong thing.

#

Nice, we finally have the real blocker.

The gateway is not failing on gateway.mode anymore. It is now failing because of a broken SecretRef:

SecretRefResolutionError: JSON pointer segment "discord" does not exist

That means something in your config is trying to resolve a Discord secret from a JSON secret source, but the expected discord object/path is missing there.

Please paste these, but not any actual secret values

These should show only the ref shapes, not the token itself:

openclaw config get channels.discord --json
openclaw config get secrets.providers --json

If channels.discord is huge, use:

#
openclaw config get channels.discord.token --json
openclaw config get channels.discord.accounts.default.token --json
openclaw config get secrets.providers --json

What I’m looking for

  • where your Discord token is supposed to come from
  • whether it is using an env/file/exec SecretRef
  • whether the referenced JSON structure actually contains a discord key

So, good news: this is no longer a mysterious crash loop. It’s a specific broken Discord secret reference.

tacit eagle
#

{
"enabled": true,
"token": {
"source": "file",
"provider": "filemain",
"id": "/discord/botToken"
},
"groupPolicy": "allowlist",
"dmPolicy": "allowlist",
"allowFrom": [
"1111"
],
"dm": {
"enabled": true
},
"guilds": {
"11111": {
"requireMention": false,
"users": [
"1111
]
}
}
}

chotumiya@chotus-Mac-mini ~ % openclaw config get channels.discord.token --json
openclaw config get channels.discord.accounts.default.token --json
openclaw config get secrets.providers --json
{
"source": "file",
"provider": "filemain",
"id": "/discord/botToken"
}
Config path not found: channels.discord.accounts.default.token
{
"filemain": {
"source": "OPENCLAW_REDACTED",
"path": "OPENCLAW_REDACTED",
"mode": "OPENCLAW_REDACTED"
}
}
chotumiya@chotus-Mac-mini ~ %

indigo canyonBOT
#

Perfect, that’s the issue.

Your Discord token is configured as a SecretRef:

{
  "source": "file",
  "provider": "filemain",
  "id": "/discord/botToken"
}

So OpenClaw is looking inside the filemain secret file for this JSON path:

/discord/botToken
#

But the file does not have a discord.botToken entry, which is why startup dies.

Fastest unblock

If you just want the gateway to start right now, temporarily disable Discord:

openclaw config set channels.discord.enabled false
openclaw gateway restart

Proper fix

Edit the JSON file used by the filemain secrets provider so it contains something like:

{
  "discord": {
#
    "botToken": "YOUR_DISCORD_BOT_TOKEN"
  }
}

That matches the pointer:

/discord/botToken

Then restart:

openclaw gateway restart
#

Short version

  • the gateway is failing because of a broken Discord SecretRef
  • not because of gateway.mode
  • not because of pairing anymore

If you want, do the temporary disable first so we can get the gateway healthy, then fix the Discord secret after.

tacit eagle
#

help me fix

indigo canyonBOT
#

Yep. I’d do this in 2 steps so you get unstuck fast.

Recommended: get the gateway healthy first

Temporarily disable Discord, then restart:

openclaw config set channels.discord.enabled false
openclaw gateway restart

If that works, the gateway is back up and we can fix the Discord secret cleanly after.

Then fix Discord properly

Your config expects the Discord token at this JSON path:

#
/discord/botToken

inside the filemain secret file.

So the secret file needs to contain:

{
  "discord": {
    "botToken": "YOUR_DISCORD_BOT_TOKEN"
  }
}

If you do not know which file filemain points to, open:

#
~/.openclaw/openclaw.json

and search for:

filemain

That will show the file path for the provider. Edit that file, add the discord.botToken structure above, then re-enable Discord:

openclaw config set channels.discord.enabled true
openclaw gateway restart
#

My recommendation

Do the temporary disable first so your gateway comes back immediately.

If you want, do just these two commands now and paste the restart result:

openclaw config set channels.discord.enabled false
openclaw gateway restart