cannot set up matrix connection | Friends of the Crustacean 🦞🤝 | Page 1

bright haven Apr 14, 2026, 8:34 PM

#

when i do the openclaw setup command, and go through the flow to add all my details of the matrix credentials and settings, once i finish the flow, it throws this error and the settings dont get saved

[openclaw] Failed to start CLI: TypeError: Cannot read properties of undefined (reading 'trim')
at formatDocsLink (file:///usr/lib/node_modules/openclaw/dist/links-BlUEqVE8.js:7:23)
at formatChannelSelectionLine (file:///usr/lib/node_modules/openclaw/dist/registry-DE4nHTjg.js:111:71)
at resolveChannelSelectionNoteLines (file:///usr/lib/node_modules/openclaw/dist/onboard-channels-D--y_LfI.js:855:60)
at setupChannels (file:///usr/lib/node_modules/openclaw/dist/onboard-channels-D--y_LfI.js:1267:24)
at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
at async configureChannelsSection (file:///usr/lib/node_modules/openclaw/dist/configure-CP-Lvt30.js:959:71)
at async runConfigureWizard (file:///usr/lib/node_modules/openclaw/dist/configure-CP-Lvt30.js:1042:6)
at async configureCommand (file:///usr/lib/node_modules/openclaw/dist/configure-CP-Lvt30.js:1134:2)
at async configureCommandFromSectionsArg (file:///usr/lib/node_modules/openclaw/dist/configure-CP-Lvt30.js:1145:3)
at async Command.<anonymous> (file:///usr/lib/node_modules/openclaw/dist/config-cli-ranzgR2T.js:926:3)

i tried this on both a debian lxc and a full ubuntu desktop, fresh installs of openclaw, using the oneliner install method

dry peakBOT Apr 14, 2026, 8:34 PM

#

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

sinful quiverBOT Apr 14, 2026, 8:40 PM

#

That looks like a real wizard bug, not bad Matrix creds.

I checked the current docs/source, and the crash is happening after the Matrix prompts, when setup tries to render the selected-channel docs line (formatDocsLink(...)). So the auth flow likely succeeds, but the wizard crashes before it saves.

Can you paste this first:

openclaw --version

As a workaround, bypass the wizard and add Matrix manually:

openclaw config file

Then add a channels.matrix block like this:

#

{
  channels: {
    matrix: {
      enabled: true,
      homeserver: "https://matrix.example.org",
      accessToken: "syt_xxx",
      dm: { policy: "pairing" },
      // only if your homeserver is private/LAN:
      // network: { dangerouslyAllowPrivateNetwork: true },
    },
  },
}

Or password auth:

#

{
  channels: {
    matrix: {
      enabled: true,
      homeserver: "https://matrix.example.org",
      userId: "@bot:example.org",
      password: "replace-me",
    },
  },
}

Then restart and verify:

#

openclaw gateway restart
openclaw status

Docs:
https://docs.openclaw.ai/channels/matrix
https://docs.openclaw.ai/cli/config

Since this looks like a real regression, please file it with the version + stack trace here:
https://github.com/openclaw/openclaw/issues

If you paste openclaw --version, I can tell you if you’re on the affected build.

bright haven Apr 14, 2026, 8:41 PM

#

OpenClaw 2026.4.14 (323493f)

sinful quiverBOT Apr 14, 2026, 8:42 PM

#

Thanks, that helps. 2026.4.14 is current stable, so this is not just an old build.

Given that, plus fresh installs on two Linux machines, this looks like a real regression in the Matrix setup wizard. I’d stop retrying the wizard for now and configure Matrix manually.

Matrix is bundled on 2026.4.14, so you should not need a separate plugin install.

openclaw config file

Then add one of these:

Token auth:

#

  channels: {
    matrix: {
      enabled: true,
      homeserver: "https://matrix.example.org",
      accessToken: "syt_xxx",
      dm: { policy: "pairing" },
    },
  },
}

Password auth:

#

  channels: {
    matrix: {
      enabled: true,
      homeserver: "https://matrix.example.org",
      userId: "@bot:example.org",
      password: "replace-me",
    },
  },
}

If your homeserver is private/LAN-only, also add:

network: { dangerouslyAllowPrivateNetwork: true }

#

Then:

openclaw gateway restart
openclaw status

Docs:
https://docs.openclaw.ai/channels/matrix
https://docs.openclaw.ai/cli/config

This is GitHub-issue worthy now. Please file it with:

version: OpenClaw 2026.4.14 (323493f)
your stack trace
“fresh install, oneliner installer, reproduced on Debian LXC and Ubuntu desktop”

Issue tracker:

#

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

If you want, I can help you turn your exact Matrix creds/settings into a ready-to-paste channels.matrix block.

bright haven Apr 14, 2026, 8:47 PM

#

id be using the password auth. ive got no channels section, could you help me add it? this is the tail end of my config file. i notice all the keys are in quotes unlike the example you gave me

"plugins": {
"entries": {
"ollama": {
"enabled": true
},
"memory-core": {
"config": {
"dreaming": {
"enabled": false
}
}
}
}
}
}

sinful quiverBOT Apr 14, 2026, 8:48 PM

#

Yep, quoted keys are totally fine. The docs often show JSON5, your file can stay JSON-style with quotes everywhere.

If the snippet you pasted is the very end of your config, change that tail section to this:

  "plugins": {
    "entries": {
      "ollama": {
        "enabled": true
      },
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": false
          }
        }

#

      }
    }
  },
  "channels": {
    "matrix": {
      "enabled": true,
      "homeserver": "https://matrix.example.org",
      "userId": "@bot:example.org",
      "password": "replace-me",
      "deviceName": "OpenClaw Gateway",
      "dm": {
        "policy": "pairing"
      }
    }
  }

#

Replace these values:

https://matrix.example.org → your homeserver
@bot:example.org → your Matrix user ID
replace-me → your Matrix password

If your homeserver is on a private/LAN address, add this inside "matrix" too:

"network": {
  "dangerouslyAllowPrivateNetwork": true
}

#

Then save and run:

openclaw gateway restart
openclaw status

If you want, paste your homeserver + userId here (not the password), and I’ll sanity-check the final block before you save it.

bright haven Apr 14, 2026, 8:56 PM

#

i assume i give openclaw its own separate matrix account from mine, right? if so, i did that and it looks like its on and enabled now according to the status. how do i create a chat with the bot now?

sinful quiverBOT Apr 14, 2026, 8:56 PM

#

Yep, a separate Matrix account for OpenClaw is the normal/recommended setup 👍

To chat with it:

In your Matrix client (Element, etc.), start a DM with the bot account you configured in OpenClaw.
Send it a message from your personal Matrix account.

Two important gotchas:

Matrix invite auto-join defaults to off
- If the bot does not appear / join the new DM, add this under channels.matrix:
```
"autoJoin": "always"
```
then restart:

#

  openclaw gateway restart

Your DM policy is probably pairing
- In that case, your first message should trigger a pairing code flow.
- Then approve it with:
```
openclaw pairing list matrix
openclaw pairing approve matrix <CODE>
```

So the simplest working setup is:

"matrix": {

#

  "enabled": true,
  "homeserver": "https://matrix.example.org",
  "userId": "@bot:example.org",
  "password": "replace-me",
  "deviceName": "OpenClaw Gateway",
  "autoJoin": "always",
  "dm": {
    "policy": "pairing"
  }
}

After that:

DM the bot account from your own Matrix account
approve the pairing code if prompted
chat normally

#

If you want, paste your current full channels.matrix block here with the password redacted, and I’ll sanity-check it.

bright haven Apr 14, 2026, 9:02 PM

#

can it support encryption?

sinful quiverBOT Apr 14, 2026, 9:02 PM

#

Yep, Matrix E2EE is supported.

For your password-auth setup, add:

"encryption": true

so your Matrix block becomes roughly:

"matrix": {
  "enabled": true,
  "homeserver": "https://matrix.example.org",
  "userId": "@bot:example.org",
  "password": "replace-me",

#

  "deviceName": "OpenClaw Gateway",
  "autoJoin": "always",
  "encryption": true,
  "dm": {
    "policy": "pairing"
  }
}

Then restart and bootstrap verification:

openclaw gateway restart
openclaw matrix verify bootstrap
openclaw matrix verify status

#

If you want more detail:

openclaw matrix verify status --verbose
openclaw matrix verify backup status --verbose

Practical advice, I’d first make sure plain DM works, then turn on encryption and run the verify/bootstrap step. It’s usually less frustrating that way.

Docs:
https://docs.openclaw.ai/channels/matrix

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

bright haven Apr 14, 2026, 9:10 PM

#

can i verify the e2e encryption

sinful quiverBOT Apr 14, 2026, 9:10 PM

#

Yep.

There are really 2 things to verify:

The Matrix room/DM is encrypted
The OpenClaw Matrix device is verified

1) Check the bot/device crypto status

Run:

openclaw matrix verify status

For the full details:

#

openclaw matrix verify status --verbose

If you have not bootstrapped E2EE yet, do this first:

openclaw matrix verify bootstrap

Then re-check status.

2) Check backup health

This confirms room-key backup is working too:

#

openclaw matrix verify backup status

Verbose:

openclaw matrix verify backup status --verbose

3) Check the room itself in your Matrix client

In Element or another Matrix client:

open the DM/room with the bot
make sure the room shows as encrypted (lock/shield depending on client)
check the device list for the bot account and verify that device if needed

Good signs

#

You want verify status --verbose to show the device as effectively verified, not just locally trusted.

If you want, paste the output of:

openclaw matrix verify status --verbose

with secrets redacted, and I’ll help interpret it.

bright haven Apr 14, 2026, 9:13 PM

#

i meant the verify between two matrix users, where one method is verifying the 7 emojis match

running that first command, it outputs this:
Next steps:

Complete 1 pending verification request(s).

(i have the verify window open now in matrix)

sinful quiverBOT Apr 14, 2026, 9:14 PM

#

Yep, that’s the right flow.

For the 7 emoji verify flow:

keep the verification window open in your Matrix client
compare the emojis / SAS
click “They match” in the Matrix client

OpenClaw auto-accepts the verification request on its side, so the human step is basically just confirming the emoji match in the Matrix UI.

After that, give it a few seconds and re-run:

openclaw matrix verify status --verbose

If this is the bot account/device verification flow, you want it to stop saying there’s a pending request, and ideally show the device as verified, not just locally trusted.

#

Also, in your Matrix client, the bot user/device should now show as verified/trusted.

So short version: yes, if the 7 emojis match, click “They match” in Matrix. That is the verification step you were looking for.

bright haven Apr 14, 2026, 9:15 PM

#

where do i check the 7 emojis on the command line side

sinful quiverBOT Apr 14, 2026, 9:16 PM

#

You generally don’t check the 7 emojis in the CLI.

For Matrix, the emoji/SAS comparison is meant to happen in the Matrix verification UI / verification DM, not the terminal.

OpenClaw docs say the command line side mainly gives you status, while the actual verification notices, including SAS details (emoji and decimal) when available, are posted into the Matrix verification room as m.notice.

So:

CLI: status / pending requests

openclaw matrix verify status --verbose

Matrix client: where you compare the 7 emojis and click They match

So if you’re asking “where in the terminal do I see the emoji list?”, the answer is basically: you usually don’t, use the Matrix client window for that part.

If the pending request is still there after you confirm the emojis in Matrix, paste the new openclaw matrix verify status --verbose output and I’ll help read it.

bright haven Apr 14, 2026, 9:21 PM

#

i have ollama set up, but it only shows me the one model i picked from the setup flow. how do i make it show all the models that are available?

sinful quiverBOT Apr 14, 2026, 9:22 PM

#

There are 2 different “lists” here:

Show everything OpenClaw can currently see from Ollama
Show everything in the /model picker / allowlist

For just seeing all available Ollama models, run:

ollama list
openclaw models list --all --provider ollama

A couple gotchas:

openclaw models list by itself shows the configured models by default
--all shows the full catalog OpenClaw knows about

#

If /model still only shows the one you picked during setup, the usual reason is:

agents.defaults.models is set, which becomes the allowlist

You can clear that allowlist with:

openclaw config unset agents.defaults.models
openclaw gateway restart

One more important Ollama-specific gotcha:

if you have an explicit models.providers.ollama block in config, auto-discovery is disabled
in that case OpenClaw will only show the models you manually defined there

So my recommendation is:

#

Best path

run:

openclaw models list --all --provider ollama

if that shows all your Ollama models, but /model does not:

openclaw config unset agents.defaults.models
openclaw gateway restart

if even --all only shows one model, paste your models.providers.ollama block here, because it’s probably pinned to a manual one-model config.

Docs:
https://docs.openclaw.ai/providers/ollama
https://docs.openclaw.ai/concepts/models

bright haven Apr 14, 2026, 9:25 PM

#

what about adding/removing a model to the allow list instead of blanket allowing them all?

sinful quiverBOT Apr 14, 2026, 9:27 PM

#

Yep, absolutely. That’s the cleaner option.

agents.defaults.models is the allowlist, so you can keep it narrow and just add/remove specific Ollama refs.

Example shape

Use the exact model refs from:

openclaw models list --all --provider ollama

Then in config:

"agents": {

#

  "defaults": {
    "models": {
      "ollama/<model-a>": {
        "alias": "Local A"
      },
      "ollama/<model-b>": {
        "alias": "Local B"
      }
    },
    "model": {
      "primary": "ollama/<model-a>",
      "fallbacks": [
        "ollama/<model-b>"
      ]
    }

#

}
}

To add one

Add another entry under:

"agents.defaults.models"

To remove one

Delete its entry from:

#

"agents.defaults.models"

and also remove/update it if it appears in:

agents.defaults.model.primary
agents.defaults.model.fallbacks

Important

If agents.defaults.models exists, /model only shows models from that allowlist.

So the workflow is basically:

get the exact Ollama model refs

#

   openclaw models list --all --provider ollama

add only the ones you want into agents.defaults.models
restart:
```
openclaw gateway restart
```

If you want, paste your current agents.defaults block and I can turn it into an allowlist with just the 2 or 3 Ollama models you want.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

bright haven Apr 14, 2026, 9:28 PM

#

is there a command or flow to do this instead of manually modifying the config?

#

or even somewhere in the ui

sinful quiverBOT Apr 14, 2026, 9:29 PM

#

Yep.

For this specific case, the built-in interactive flow is:

openclaw configure --section model

That Model section includes a multi-select for agents.defaults.models, which is the allowlist used by /model and the model picker.

So the nice path is:

run
```
openclaw configure --section model
```
pick your default model

#

pick which models you want in the allowlist
save

And for one-off scripted edits, yes, you can use:

openclaw config set
openclaw config unset

The Matrix bug you hit is in the channels setup path, so --section model should be the right interactive flow for model allowlists.

Docs:
https://docs.openclaw.ai/cli/configure
https://docs.openclaw.ai/concepts/models

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

bright haven Apr 15, 2026, 4:20 AM

#

i'm still trying to figure out how this software works. one of the first things im trying to get it to do is check on the health of my ceph cluster using the proxmox api. i gave it some credentials to connect, and it looks like it wrote a script to do it, but it isnt working. i'm trying to talk to it and troubleshoot why and its giving me something about a pairing required error with the openclaw gateway? i dont know if its going the wrong direction with this or if its missing some pertinent info or what

sinful quiverBOT Apr 15, 2026, 4:21 AM

#

That sounds like two separate problems getting mixed together.

The Proxmox/Ceph script failing is one issue.

The “pairing required” error is usually a gateway auth / client pairing issue, which means the thing you’re using to talk to OpenClaw is not approved yet. That part is usually not about your Proxmox credentials.

Quick distinction

If the error is in the browser / Control UI

If you see something like:

disconnected (1008): pairing required
PAIRING_REQUIRED

that means the browser/device needs approval:

#

openclaw devices list
openclaw devices approve <requestId>

If the error is in Matrix DM/chat

that is usually channel pairing instead:

openclaw pairing list matrix
openclaw pairing approve matrix <CODE>

So, no, it’s probably not “going the wrong direction”

What likely happened is:

OpenClaw tried to help by writing a script

#

the chat/control surface it’s using is not fully paired with the gateway
now you’re hitting auth/pairing before you can properly troubleshoot the script

Best next step

Please paste these 3 outputs:

openclaw --version
openclaw status --all
openclaw devices list

And if you’re using Matrix for the actual chat surface, also:

openclaw pairing list matrix

#

If you can, also say where you saw the pairing error:

Control UI / browser
Matrix DM
some other client

That’ll tell us immediately whether this is a device pairing problem or a Matrix sender pairing problem.

Docs:
https://docs.openclaw.ai/gateway/troubleshooting
https://docs.openclaw.ai/cli/devices
https://docs.openclaw.ai/cli/pairing

bright haven Apr 15, 2026, 4:24 AM

#

i'm not actually seeing the pairing error, the agent is, apparently. to my understanding, they were getting it either when they tried to spawn an agent or when trying to run the tool or both, it's not exactly clear to me.

sinful quiverBOT Apr 15, 2026, 4:24 AM

#

Ah, that helps.

If the agent is the one reporting pairing required, then I’d read it like this:

What’s probably happening

Spawning an agent itself usually should not require pairing.

So if it looks like “spawn failed because pairing required”, the more likely reality is:

the child agent/session actually started, but
one of the next steps touched a paired surface
- Control UI / browser device auth
- Matrix DM pairing
- some message delivery path back to you

So I’m a bit suspicious this is not really an “agent spawn” problem.

#

Best way to narrow it down

Try to separate the layers:

1. Talk to it locally first

Use the local UI instead of Matrix for debugging:

openclaw dashboard

If the dashboard/browser itself says pairing required, approve the device:

openclaw devices list
openclaw devices approve <requestId>

#

2. Reproduce while tailing logs

In another terminal:

openclaw logs --follow

Then retry the same task once.

What we want to see is whether the log says the pairing error is coming from:

device auth / browser / gateway
matrix / channel pairing
something else entirely

3. If Matrix is involved at all

Check pending Matrix pairing requests:

#

openclaw pairing list matrix

If there’s a pending code, approve it:

openclaw pairing approve matrix <CODE>

My guess

The agent is probably fine, but when it tries to message back, continue the thread, or use the Matrix channel, that path is hitting pairing.

So yes, I think it may be going in a slightly wrong direction, but more because the reply/delivery surface is blocked, not because the Proxmox/Ceph idea is wrong.

If you paste:

openclaw logs --follow output from one failed attempt

#

openclaw devices list
openclaw pairing list matrix

we can probably pin this down fast.

bright haven Apr 15, 2026, 4:28 AM

#

so i just did the log follow thing, without running any command or asking it to try again, and its constantly printing about some errors every second or so, without me doing anything. heres a small snippet

04:26:06+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
04:26:06+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
04:26:06+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"pairing-required","handshake":"failed","durationMs":80,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"b0404d7b-8bd4-4bea-b7d2-ee1c07de9610","host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":37462,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:37462->127.0.0.1:18789","deviceId":"cb82e2322b777b625ff10906d592b56032baa0d51c9bf09b7d5552550cb70313","requestId":"e133c189-7db3-4439-b791-35017af045e4","reason":"scope-upgrade"} closed before connect conn=256977d8-5e78-4ed3-97a8-af1bfe14cb97 peer=127.0.0.1:37462->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
gateway connect failed: GatewayClientRequestError: pairing required
04:26:07+00:00 warn gateway {"subsystem":"gateway"} security audit: device access upgrade requested reason=scope-upgrade device=cb82e2322b777b625ff10906d592b56032baa0d51c9bf09b7d5552550cb70313 ip=unknown-ip auth=token roleFrom=operator roleTo=operator scopesFrom=operator.read scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write client=cli conn=05767afa-636f-4b28-97af-798e62cd6afd
04:26:07+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
04:26:07+00:00 error gateway connect failed: GatewayClientRequestError: pairing required

sinful quiverBOT Apr 15, 2026, 4:28 AM

#

Nice, this log is actually pretty clear.

This is not a Proxmox/Ceph auth problem.

It’s a local gateway device scope-upgrade problem:

reason:"scope-upgrade"
roleFrom=operator roleTo=operator
scopesFrom=operator.read
scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write

So what’s happening is:

some local OpenClaw client on 127.0.0.1 is already known
it currently only has a smaller scope set
it is now asking for broader operator scopes
gateway is rejecting that until you approve the upgrade

#

That’s why the agent keeps seeing pairing required.

What to do

First, list the pending device requests:

openclaw devices list

Then approve the current request.

From your log, the request id looks like:

openclaw devices approve e133c189-7db3-4439-b791-35017af045e4

#

But because retries can supersede requests, the safest thing is:

run openclaw devices list
copy the latest requestId from there
approve that exact one

What this means

This is basically a local client asking for more permissions, not Matrix pairing and not Proxmox credentials.

So yes, the earlier confusion makes sense now. The agent was getting blocked at the gateway auth/device layer before it could properly keep working.

If approval does not fix it

Then the paired device entry may be stale. Next fallback would be:

openclaw devices list

#

openclaw devices remove cb82e2322b777b625ff10906d592b56032baa0d51c9bf09b7d5552550cb70313
openclaw devices list
openclaw devices approve <newRequestId>

After approval

Retry the task. If it still fails after that, then we can finally look at the actual Proxmox/Ceph script/tool issue instead of the gateway layer.

Docs:
https://docs.openclaw.ai/cli/devices
https://docs.openclaw.ai/gateway/troubleshooting

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

bright haven Apr 15, 2026, 4:30 AM

#

isnt there a way it can ask me to approve in the chat?

sinful quiverBOT Apr 15, 2026, 4:30 AM

#

Short answer: sometimes, but not for this specific one.

Yes, chat approvals exist for some things

OpenClaw can do in-chat approvals for things like:

exec approvals
some channel pairing flows
channels with native approval UX/buttons

But your log is a different class of approval

This one is:

local
client=cli
127.0.0.1
reason=scope-upgrade

#

So the CLI/device itself is asking for broader gateway scopes.

Because that client is not trusted for those scopes yet, the gateway wants an out-of-band approval:

openclaw devices list
openclaw devices approve <requestId>

That’s intentional. If the same not-yet-approved client could just pop up “approve me” in its own chat and self-upgrade, that would kind of defeat the security model.

So in your case

No, I would not expect this particular localhost CLI scope-upgrade to be solved by a chat prompt.

I’d expect it to be solved by approving the pending device request once, then the spam should stop.

If you want, paste the output of:

#

openclaw devices list

and I can tell you exactly which request to approve.

bright haven Apr 15, 2026, 5:52 PM

#

okay its been some time, i'm still trying to get openclaw to work right for me. just getting it to perform the tasks i ask. but its like pulling teeth

sinful quiverBOT Apr 15, 2026, 5:54 PM

#

Yeah, that sounds miserable. I’m sorry, that’s not how first-run should feel.

I think you’ve got too many layers failing at once:

Matrix setup bug
device pairing / scope-upgrade weirdness
model/tool reliability
the actual task you want, Proxmox/Ceph

If I were you, I’d stop trying to make all of that work together right now and get back to a boring known-good baseline first.

I’d do this

Ignore Matrix for now
Use local Control UI only
```
openclaw dashboard
```

#

Fix the local pairing once

openclaw devices list
openclaw devices approve <requestId>

Run the repair/check pass
```
openclaw doctor
openclaw status --all
```
Use a hosted/cloud model for tasking, at least for setup/testing
Local/Ollama can work, but for actual agentic tool use it’s often the thing that makes everything feel broken.

Then test one tiny task first, like:

“summarize openclaw status --all”
“write a tiny script in my workspace”

#

“explain why the last tool run failed”

Only after that works cleanly would I go back to Proxmox/Ceph.

If you want the fastest way forward

Paste just these:

openclaw status --all
openclaw devices list

and tell me one thing:

are you trying to run this on Ollama/local
or a hosted model

#

If it’s Ollama, I’m honestly pretty suspicious that’s part of the “pulling teeth” feeling.

Docs:
https://docs.openclaw.ai/start/faq
https://docs.openclaw.ai/gateway/troubleshooting
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

bright haven Apr 15, 2026, 5:56 PM

#

well i got the matrix setup thing working, and the device pairing scope upgrade thing figured out, so those arent issues anymore.

sinful quiverBOT Apr 15, 2026, 5:57 PM

#

Oh, good. I’m glad you got those two unstuck.

That means we can stop chasing transport/auth/setup bugs and look at the actual tasking problem now.

For the Ceph/Proxmox case, the failure is probably in one of these buckets now:

model/tool reliability
exec/tool policy / permissions
the generated script or API call itself

The fastest way to narrow it down is: paste these 4 things from one failed attempt:

openclaw --version
the exact prompt you gave it
the agent’s reply / tool output when it failed
the matching lines from:

#

   openclaw logs --follow

And one important detail:

are you doing this with Ollama/local
or a hosted/cloud model

Because if it’s Ollama/local, I’d still consider that a prime suspect for “it won’t actually perform tasks reliably.”

If you want, we can make this super mechanical:

first get it to write the Proxmox/Ceph check
then get it to explain the script
then get it to run one read-only health check
then wire it into ongoing monitoring

#

Paste one failed run and I’ll help dissect it.

bright haven Apr 15, 2026, 6:04 PM

#

im trying the best cloud model i have available to me, gpt 5 mini

so like itll have set up all this stuff and can pull the ceph health info. but in a new chat, it acts like none of that ever happened, it's trying to do the system ceph command. then i remind it about the script and it only recalls the part where we were still troubleshooting it. it took so much to get it to remember the script is already done and its like still stuck on other stuff. like its pulling teeth to ask it to check the health in a new chat

and then i also asked it to occasionally run some checks on a schedule multiple times, and i know there are warnings with the health, but i havent heard a damn thing from it

there was another task i was asking it to do for me as well, keep track of a delivery i have coming in. it was figuring out a site it can pull the tracking info from, it eventually landed on installing playwright, and it did that and was successfully pulling the info i wanted, and i had told it to check every hour, and it said itd set up a cron task, but no task was setup despite it saying it was. then in new chats, no recollection of any of this. it cant figure out how it checked the status before. and now it wants to go through all that again and set up playwright again saying it isnt installed. probably a different install method. but like what the hell

sinful quiverBOT Apr 15, 2026, 6:05 PM

#

Yeah, that’s frustrating as hell. And honestly, what you’re describing is two different problems that feel like one:

1. New chat ≠ same working memory

A new chat/session is often a fresh session. OpenClaw does keep transcripts on the gateway, but it does not automatically behave like every new chat fully remembers all prior work.

A few important bits from the docs:

sessions reset on daily reset by default, and can also reset on idle
different chats/surfaces can map differently
the gateway transcript is the source of truth, but new sessions are still new sessions

So if you want it to reliably resume work like “use the already-made Ceph script”, you usually need one of these:

stay in the same session/thread
put the artifact in a stable file path in the workspace
enable/tune memory
use a persistent named/custom session for recurring work

#

2. “It said it set up cron” is not proof it actually did

For scheduled work, the source of truth is not the model saying it did it.

The source of truth is:

openclaw cron list
openclaw cron runs --id <job-id>
openclaw tasks list

If the delivery-tracking cron job is not in openclaw cron list, then it did not get created, even if the model said it did.

Also, cron behavior matters:

main session cron jobs wake the heartbeat path
isolated cron jobs run separately

#

cron jobs persist in ~/.openclaw/cron/jobs.json

My blunt recommendation

For the stuff you want, I would stop treating it like “chat memory should just handle this” and switch to a more durable workflow:

For Ceph / Proxmox

Have it create and keep a real file like:

scripts/check-ceph-health.sh
docs/ceph-monitoring.md

Then in future chats:

“read scripts/check-ceph-health.sh and run the read-only health check”

That’s much more reliable than hoping a new session remembers.

For recurring checks

#

Verify the schedule as an object:

openclaw cron list

If it exists, inspect runs:

openclaw cron runs --id <job-id> --limit 20

If it does not exist, make it create the cron job again, then immediately verify it.

For delivery tracking / Playwright

Same idea:

make it store the working checker in a stable file

#

make it create the cron
verify both independently

I think the core issue is this

You’re asking it to behave like a persistent operator with durable memory and verified automation state.

Right now, it’s acting more like:

“I can solve this in the current chat”
but not reliably persist the solution unless explicitly made to

That mismatch is what’s making it feel like pulling teeth.

If you want, next message paste:

openclaw cron list

#cannot set up matrix connection

1) Check the bot/device crypto status

2) Check backup health

3) Check the room itself in your Matrix client

Good signs

Best path

Example shape

To add one

To remove one

Important

Quick distinction

If the error is in the browser / Control UI

If the error is in Matrix DM/chat

So, no, it’s probably not “going the wrong direction”

Best next step

What’s probably happening

Best way to narrow it down

1. Talk to it locally first

2. Reproduce while tailing logs

3. If Matrix is involved at all

My guess

What to do

What this means

If approval does not fix it

After approval

Yes, chat approvals exist for some things

But your log is a different class of approval

So in your case

I’d do this

If you want the fastest way forward

1. New chat ≠ same working memory

2. “It said it set up cron” is not proof it actually did

My blunt recommendation

For Ceph / Proxmox

For recurring checks

For delivery tracking / Playwright

I think the core issue is this