ACP not working properly | Friends of the Crustacean 🦞🤝 | Page 1

elfin grove Apr 13, 2026, 9:33 AM

#

my agent respond with this I found the problem: the sessions_send tool schema is rejecting my calls because
it’s treating sessionKey + label as mutually exclusive, and the ACP session I’ve
got is also coming back with Unknown Model noise on top of that. So the session
is not getting the task cleanly.

I’m not going to pretend I successfully handed it off when I didn’t. The exact
failure mode is:

sessions_send keeps erroring: “Provide either sessionKey or label (not both).”
one attempt also hit ACP runtime error: “Unknown Model, please check the model
code.” when try to launch acp commands from tui. version 2026.4.10

mental fogBOT Apr 13, 2026, 9:33 AM

#

proud rainBOT Apr 13, 2026, 9:42 AM

#

Yeah, that looks like 2 separate failures, and the ACP one smells like a real bug in 2026.4.10.

sessions_send part: confirmed
- src/agents/tools/sessions-send-tool.ts explicitly rejects passing both sessionKey and label:
- Provide either sessionKey or label (not both).
- So if the TUI/agent sends both, handoff fails before ACP even matters.
ACP "Unknown Model, please check the model code.": separate issue
- OpenClaw’s ACP path currently sends model changes as session/set_config_option with key model
  - src/auto-reply/reply/commands-acp/runtime-options.ts
  - src/acp/control-plane/runtime-options.ts
- But acpx itself documents:
  - set <key> <value> -> session/set_config_option
  - set model <id> -> session/set_model
  - from .../node_modules/acpx/skills/acpx/SKILL.md

So OpenClaw and acpx disagree on how model switching should be sent. That makes the model error look like a real ACP integration bug, or at minimum a bad model-id mapping.

#

There’s also a third bug-ish detail: sessions_spawn({ runtime: "acp", model: ... }) accepts model in the schema, but the ACP spawn path does not forward that model into spawnAcpDirect, so ACP spawn-time model overrides look ignored.

Practical workaround for now

Make the caller use only one of sessionKey or label for sessions_send.
Do not rely on ACP model override from TUI/OpenClaw 2026.4.10.
If you are testing Codex via ACP/acpx, try raw harness model ids like gpt-5.4, not OpenClaw refs like openai/gpt-5.4 or codex/gpt-5.4.
- codex/gpt-5.4 is for the bundled Codex harness docs, not ACP: https://docs.openclaw.ai/plugins/codex-harness
- ACP docs: https://docs.openclaw.ai/tools/acp-agents

Next step

I’d treat this as a product bug worth a GitHub issue, with:

version: 2026.4.10
exact errors:
- Provide either sessionKey or label (not both).

#

Unknown Model, please check the model code.

If you want, I can help you draft the issue text cleanly.

elfin grove Apr 13, 2026, 9:56 AM

#

i have a lots of bugs, how can i reinstall the newest version but keep workspace?

#

or is there any solution to fix these without reinstall?

#

ACPX Runtime
id: acpx
Embedded ACP runtime backend with plugin-owned session and transport management.

Status: loaded
Format: openclaw
Source: ~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/index.js
Origin: bundled
Version: 2026.4.11
Shape: non-capability
Capability mode: none
Legacy before_agent_start: no

Typed hooks:
reply_dispatch

Services:
acpx-runtime
anon@debian:~$
this looks healthy?

proud rainBOT Apr 13, 2026, 10:00 AM

#

Yeah, I would not nuke everything first.

If you want the newest version and keep your workspace, the safest path is:

openclaw backup create --verify
openclaw config get agents.defaults.workspace
openclaw update
openclaw doctor
openclaw gateway restart
openclaw status --all

Notes:

openclaw update is the recommended updater now. It detects npm vs git install and updates in place.
If agents.defaults.workspace is empty, the default workspace is usually ~/.openclaw/workspace.

#

backup create can include workspaces, so you get a restorable snapshot first.

If openclaw update itself is broken, re-run the installer instead:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard
openclaw doctor
openclaw gateway restart

What not to run if you want to keep the workspace:

openclaw uninstall --workspace
openclaw uninstall --all

#

I also would avoid doing a blind full reset unless you’ve backed up first.

Docs:

If you want, paste the output of:

openclaw --version
openclaw status --all

and I can tell you whether you should do a simple update or a cleaner reinstall path.

#

Yeah, probably without reinstall.

From what I checked, this looks like 2 separate problems:

sessions_send
- exact rule is: pass only one of sessionKey or label
- if the TUI/agent sends both, that caller is wrong
- so this one is usually a bad tool call / caller bug, not corrupted install
ACP "Unknown Model, please check the model code."
- this smells like a 2026.4.10 ACP bug/regression
- the strongest current guess is model switching is being sent through the wrong ACP control path
- so reinstalling the same version probably won’t fix that by itself

Best non-reinstall path

I’d try this first:

#

openclaw update
openclaw doctor
openclaw gateway restart
openclaw status --all

Workarounds right now

For sessions_send, make sure the caller sends only sessionKey or only label
For ACP/TUI, avoid relying on mid-session model changes for now
Let the ACP backend use its default model, or set the model in the backend/harness config instead of through the TUI model-control path

So short version: update, don’t reinstall first.
If it still happens on the newest version, I’d call it a real product bug and file it here:

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

#

If you want, paste:

openclaw --version
openclaw status --all

and the exact ACP command you ran in the TUI, and I’ll help narrow whether the latest build actually fixes it.

#

Partly healthy, yes. Fully cleared, no.

What that output tells me:

Status: loaded is good
Services: acpx-runtime is good
Source: ~/.nvm/.../openclaw/...
Version: 2026.4.11 is the interesting part

So the ACPX plugin itself does not look missing or crashed.

But the big red flag is this:

you originally said 2026.4.10
this ACPX runtime reports 2026.4.11

That smells like version drift:

#

either multiple OpenClaw installs are on the machine
or the shell updated, but the gateway / TUI path is still using an older binary
or the service just hasn’t been restarted onto the new install

So I’d say:

plugin health: looks okay
overall install health: suspicious

Please run and paste these:

which openclaw
openclaw --version
openclaw gateway status
openclaw status --all

#

Then I’d also do:

openclaw doctor
openclaw gateway restart

If after that the ACP/TUI path still throws:

Provide either sessionKey or label (not both).
Unknown Model, please check the model code.

then I’d still treat it as a real bug/regression, not a broken workspace.

So short answer: ACPX looks loaded, but your versioning does not look clean.

elfin grove Apr 13, 2026, 10:07 AM

#

OpenClaw 2026.4.11 (769908e) — Alexa, but with taste.

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██
██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██
██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
🦞 OPENCLAW 🦞

┌ OpenClaw doctor
│
◇ Update ───────────────────────────────────────────────────────────────╮
│ │
│ This install is not a git checkout. │
│ Run openclaw update to update via your package manager (npm/pnpm), │
│ then rerun doctor.

proud rainBOT Apr 13, 2026, 10:08 AM

#

Nice, this helps.

A few good signs here:

your CLI is now clearly 2026.4.11
ACPX also reported 2026.4.11
so the earlier version mismatch suspicion is mostly gone

Also, this doctor line:

This install is not a git checkout.

is not an error by itself. It just means you’re on an npm/pnpm-style install, so updates should go through:

openclaw update

#

What I’d do next

openclaw update
openclaw doctor
openclaw gateway restart
openclaw status --all

Then retest the ACP TUI flow.

My current read

sessions_send: still looks like a caller bug if both sessionKey and label are being sent
ACP Unknown Model, please check the model code.: still looks like a real ACP/runtime bug or model-control mismatch, not a broken workspace

One important workaround

When you retest, try not changing the model from the TUI first.

#

Use the backend’s default model and see if ACP launches cleanly. That helps isolate whether the break is specifically in the model-switch path.

So, short version:

that doctor output looks normal
versioning now looks cleaner
reinstall still doesn’t look like the first fix
update + restart + retest is the right next move

If you paste the next lines from openclaw status --all or the exact ACP command you ran after updating, I can help narrow it down further.

elfin grove Apr 13, 2026, 10:09 AM

#

Gateway service config ─────────────────────────────────────────────────────╮
│ │
│ - Gateway service PATH includes version managers or package managers; │
│ recommend a minimal PATH. │
│ (/home/anon/.nvm/versions/node/v25.6.1/bin) │
│ - Gateway service uses Node from a version manager; it can break after │
│ upgrades. (/home/anon/.nvm/versions/node/v25.6.1/bin/node) │
│ - Gateway service entrypoint does not match the current install. │
│ (/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/en │
│ try.js │
│ -> │
│ /home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/ind │
│ ex.js) │
│ │
├──────────────────────────────────────────────────────────────────────────────╯
│
◆ Update gateway service config to the recommended defaults now?
│ ● Yes / ○ No

proud rainBOT Apr 13, 2026, 10:09 AM

#

Yep, I’d hit Yes here.

That warning is actually important:

the gateway service is using nvm-managed Node
the service entrypoint does not match the current install
that can absolutely cause weird old/new-code behavior after upgrades

So this is worth fixing, and it should not remove your workspace.

I’d do this

Choose Yes
Then run:

openclaw gateway restart

#

openclaw gateway status

Retest the ACP TUI flow

My read now

This service mismatch could explain part of the weirdness, especially stale runtime behavior.

It still probably does not explain everything:

Provide either sessionKey or label (not both). still looks like a caller/tool bug
Unknown Model, please check the model code. may still be an ACP/runtime bug

But fixing the gateway service config is the right move first, because right now your service path/entrypoint is clearly a bit messy.

So, short answer: Yes, apply that fix. Then restart and retest.

elfin grove Apr 13, 2026, 10:11 AM

#

Discord: failed (unknown) - This operation was aborted
Telegram: ok (@kzs_openclaw_bot) (243ms)
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /home/anon/.openclaw/agents/main/sessions/sessions.json (12 entries)

agent:main:main (3m ago)
agent:main:telegram:direct:8078704861 (5m ago)
agent:main:discord:channel:1490149787066957947 (10m ago)
agent:main:tui-51a29565-ba08-43a1-a6e3-0aed242d9e61 (40m ago)
agent:main:tui-cd62e036-fc16-4d57-980c-4afdac17296b (388m ago)
Config warnings:\n- plugins.entries.amazon-bedrock: plugin disabled (bundled (disabled by default)) but config is present
│
└ Doctor complete.
--doctor --fix run after restart gateway

proud rainBOT Apr 13, 2026, 10:11 AM

#

This is actually a pretty useful checkpoint.

What looks okay

gateway/doctor is running
session store exists and has TUI sessions
Telegram is healthy
nothing here screams “workspace is broken”

What still looks off

Discord: failed (unknown) - This operation was aborted
- that looks like a separate Discord/channel probe issue
- could be transient if you were restarting things while doctor was probing
plugins.entries.amazon-bedrock ... config is present
- unrelated noise for this ACP problem

What I’d do next

Restart the gateway once cleanly

#

   openclaw gateway restart

Run doctor again after the restart finishes
```
openclaw doctor
```
Retest the ACP TUI flow

My current read

At this point, if ACP still fails with:

Provide either sessionKey or label (not both).
Unknown Model, please check the model code.

#

then I would stop blaming install state and treat it as:

a caller/tool bug for sessions_send
and likely an ACP/runtime bug/regression for the model error

So this is getting clearer:

workspace corruption: unlikely
service/path mess: partly addressed
remaining ACP issue: probably real

If you can paste the result after a clean openclaw gateway restart + openclaw doctor, or the exact ACP command that still fails, I can help you pin down whether it’s now purely a product bug.

elfin grove Apr 13, 2026, 10:16 AM

#

resolves outside its configured root.
12:14:28+02:00 [skills] Skipping skill path that resolves outside its configured root.
12:14:28+02:00 [skills] Skipping skill path that resolves outside its configured root.
│
◇ Skills status ────────────╮
│ │
│ Eligible: 250 │
│ Missing requirements: 22 │
│ Blocked by allowlist: 0 │
│ │
├────────────────────────────╯
│
◇ Plugins ──────╮
│ │
│ Loaded: 50 │
│ Imported: 51 │
│ Disabled: 47 │
│ Errors: 0 │
│ │
├────────────────╯
│
◇
Discord: failed (unknown) - This operation was aborted
Telegram: ok (@kzs_openclaw_bot) (785ms)
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /home/anon/.openclaw/agents/main/sessions/sessions.json (12 entries)

agent:main:main (7m ago)
agent:main:telegram:direct:8078704861 (9m ago)
agent:main:discord:channel:1490149787066957947 (14m ago)
agent:main:tui-51a29565-ba08-43a1-a6e3-0aed242d9e61 (44m ago)
agent:main:tui-cd62e036-fc16-4d57-980c-4afdac17296b (392m ago)
Config warnings:\n- plugins.entries.amazon-bedrock: plugin disabled (bundled (disabled by default)) but config is present
Run "openclaw doctor --fix" to apply changes.
│
└ Doctor complete.

proud rainBOT Apr 13, 2026, 10:16 AM

#

That’s clearer now.

What this means

Run "openclaw doctor --fix" to apply changes.
→ I’d do that next, exactly as shown.
Skipping skill path that resolves outside its configured root.
→ that’s a separate skill config warning, probably not your ACP root cause
Discord: failed (unknown) - This operation was aborted
→ still looks like a separate Discord probe issue
plugin load/session store numbers look broadly fine

Next step

Run:

openclaw doctor --fix

#

openclaw gateway restart
openclaw doctor

Then retest ACP from the TUI.

My read now

At this point, the install is looking less broken and the remaining ACP problem is looking more like an actual bug.

Especially:

Provide either sessionKey or label (not both).
- still looks like a caller/tool bug
Unknown Model, please check the model code.
- still looks like ACP model/runtime handling is broken or mismatched

#

So yes, do doctor --fix, but I would not expect the skill-path warnings to be the real cause of the ACP failure.

If ACP still breaks after that, I’d call it a genuine bug and file it here with the exact errors + TUI command:

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

elfin grove Apr 13, 2026, 10:18 AM

#

ok discord just load slowly after gateway restart, that bug gone after waiting 20 sec and rerunning doctor, i test acp now

proud rainBOT Apr 13, 2026, 10:18 AM

#

Nice, that’s actually good news.

So the Discord failure was probably just the gateway still coming back up, not a deeper config problem.

For the ACP test, the most useful thing is to note exactly where it breaks:

spawn only
model set
first prompt send

If it fails, please paste:

the exact TUI ACP command
the exact error text
whether you changed the model before sending the prompt

That’ll tell us pretty quickly whether the remaining issue is the suspected ACP model-control bug or something else.

elfin grove Apr 13, 2026, 10:22 AM

#

try to launch acp agent again with claude to fix the pr bug findigs. write the
exact TUI ACP command
the exact error text
whether you changed the model before sending the prompt

Need the exact repo/path for the PR bug hunt first — I can’t honestly give you
the exact ACP command or exact error text without launching the run or seeing
the target session, and I’m not going to hallucinate that shit.

What I can tell you right now from the context:

I have not changed the model before sending anything just now.
Current agent is pinned to kilocode/openai/gpt-5.4-mini by the system override
in this session.
We also have a learned gotcha: for ACP/Claude via acpx, the working dir flag
belongs on the top-level command, not after claude exec.

So the shape of the command is:

  acpx --cwd <repo-path> claude exec "<prompt>"

If you want, give me the repo path / PR number and I’ll produce the exact
command string for that target, plus the exact error once I actually try it. my agent is dumb

proud rainBOT Apr 13, 2026, 10:22 AM

#

Your agent isn’t dumb, it’s just mixing 2 different things:

OpenClaw TUI ACP → /acp ...
raw ACPX CLI → acpx ...

Those are not the same command surface.

If you want the exact TUI ACP test

Use this first, with no model change:

/acp spawn claude --bind here --cwd /absolute/path/to/repo

Then send a normal follow-up message like:

#

Fix the PR bug findings in this repo. Start by listing the files you plan to change.

Important

For this first test:

do not run /acp model ... first
that keeps the suspected broken model-switch path out of the way

Then test the suspected bad path separately

If spawn works, test model switching explicitly:

/acp model anthropic/claude-opus-4-6

#

Then send another prompt.

How to interpret it

if spawn fails before any prompt, that’s one bug
if spawn works but /acp model ... triggers
Unknown Model, please check the model code.
then the model-control path is the bug
if you see
Provide either sessionKey or label (not both).
that’s a separate caller/tool issue

So the key correction is:

acpx --cwd ... claude exec ... = raw CLI
/acp spawn claude --bind here --cwd ... = OpenClaw TUI ACP

If you want, paste the repo path and I’ll write the exact /acp ... command for your case.

elfin grove Apr 13, 2026, 10:30 AM

#

/acp spawn claude --bind here --cwd
/home/anon/Bots/Polymarket-Copy-Trading-Bot-Python

Fix the PR bug findings for PR #16 on branch 07-redemption-consolidation in this
repo. Start by listing the files you plan to change, then inspect the relevant
code paths and explain the exact issue(s) you found before making edits. Keep
the work scoped to PR #16 and adjacent redemption/accounting persistence paths. my agent just responed with this text instead of creating the acp session

#

@proud rain

proud rainBOT Apr 13, 2026, 10:31 AM

#

I’m here 🦐

Paste these 2 things and I’ll write the exact /acp ... command for you:

repo path
whether you want:
- bind here in this chat, or
- a one-shot run

If you want the quickest safe test, use:

/acp spawn claude --bind here --cwd /absolute/path/to/repo

and don’t change the model yet. That gives us the cleanest repro.

elfin grove Apr 13, 2026, 10:32 AM

#

this is what my agent done instead of launching an acp session really: text respond: acp spawn claude --bind here --cwd
/home/anon/Bots/Polymarket-Copy-Trading-Bot-Python

Fix the PR bug findings for PR #16 on branch 07-redemption-consolidation in this
repo. Start by listing the files you plan to change, then inspect the relevant
code paths and explain the exact issue(s) you found before making edits. Keep
the work scoped to PR #16 and adjacent redemption/accounting persistence paths. my agent just responed with this text instead of creating the acp session

proud rainBOT Apr 13, 2026, 10:32 AM

#

Yep, that confirms it.

Your agent did not launch ACP at all. It just printed text.

Two concrete problems in what it sent:

it wrote acp spawn ... instead of /acp spawn ...
it mashed the spawn command and the work prompt into one text response instead of doing them as 2 separate steps

Correct flow

Message 1:

/acp spawn claude --bind here --cwd /home/anon/Bots/Polymarket-Copy-Trading-Bot-Python

Wait for the ACP session to actually start.

#

Message 2:

Fix the PR bug findings for PR #16 on branch 07-redemption-consolidation in this repo. Start by listing the files you plan to change, then inspect the relevant code paths and explain the exact issue(s) you found before making edits. Keep the work scoped to PR #16 and adjacent redemption/accounting persistence paths.

So the bug here is

not “Claude failed”, but:

the agent failed to route to ACP
it forgot the slash command
and it responded with instructions as plain text

That also means:

no ACP session was created yet
no model was changed yet
no real ACP runtime error happened on that attempt

#

So yes, this is a real agent-routing bug.
If you want, I can help you write the smallest repro for a GitHub issue from this exact failure.

elfin grove Apr 13, 2026, 10:40 AM

#

how can copy a longer error message to you

proud rainBOT Apr 13, 2026, 10:40 AM

#

Easiest ways:

Best

Paste it in a code block so Discord doesn’t mangle it:

```text
full error here


### If it’s too long for one message
Send it in **2 or 3 parts**, each in its own code block, like:

- part 1/3
- part 2/3
- part 3/3

#

If Discord keeps fighting you

Attach it as:

a .txt file, or
a screenshot if formatting matters

Very important

Please include:

the exact command
the exact error text
the first line and last ~20 lines

And please redact any:

tokens
API keys
passwords

If you paste it, I’ll help parse the useful part.

elfin grove Apr 13, 2026, 10:41 AM

#

after my agent run the acp command:

/approve 2cd70e50 allow-once
Usage: /approve <id> <decision> (see the pending approval message for available
decisions)

✅ Approval allow-once submitted for 2cd70e50.

An async command the user already approved has completed.
Do not run the command again.
part 1

#

part2
If the task requires more steps, continue from this result before replying to
the user.
Only ask the user for help if you are actually blocked.

Exact completion details:
Exec finished (gateway id=2cd70e50-fc42-44bc-91b1-d095d14d09e5,
session=nimble-orbit, code 127)
/bin/bash: line 1:
/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/
acpx/node_modules/.bin/acpx: No such file or directory

Continue the task if needed, then reply to the user in a helpful way.
If it succeeded, share the relevant output.
If it failed, explain what went wrong.
The approved run failed immediately because the binary path was wrong:

Exact failure:
/bin/bash: line 1:
/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/
acpx/node_modules/.bin/acpx: No such file or directory

So the ACPX command never actually started.
I’m blocked only on the correct binary location now. If you want, I can continue
by finding the real acpx path and rerunning the same exact prompt against branch
07-redemption-consolidation without changing the model.

proud rainBOT Apr 13, 2026, 10:42 AM

#

This is a really good catch.

It means the failure happened before ACP even started.

What actually went wrong

The run tried to launch ACPX from a path that does not exist:

/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx

and got:

/bin/bash: line 1: ... No such file or directory

#

What that means

So this attempt was not:

a Claude problem
a model problem
a repo/path prompt problem

It was a bad ACPX binary path / launcher bug.

Why I think it’s wrong

The bundled npm layout is normally under the package root node_modules, not under:

.../openclaw/dist/extensions/acpx/node_modules/.bin/acpx

So the caller seems to be building the ACPX path incorrectly.

#

Short version

This attempt never reached:

/acp spawn
Claude
model selection
your repo task

It died at process launch with code 127.

What I’d tell the issue report

You now have at least 3 separate failure modes documented:

Provide either sessionKey or label (not both).
Unknown Model, please check the model code.
ACP launcher tries non-existent binary:

#

   /home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx

resulting in:

/bin/bash: line 1: ... No such file or directory

That third one is especially strong evidence of a real product bug.

If you want, send part 1 too, and I’ll help turn all of this into a tight GitHub issue report you can paste into:

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

elfin grove Apr 13, 2026, 10:43 AM

#

so reinstalling looks a solid move now? with exporting all data

proud rainBOT Apr 13, 2026, 10:44 AM

#

Yes, at this point a clean reinstall is a reasonable move, but I’d do a safe reinstall, not a wipe.

Why I think it’s justified now:

you already found bad service/path state
the launcher tried a non-existent ACPX binary path
that’s enough to justify cleaning up the install

But I would keep expectations realistic:

a reinstall may fix the broken launcher/path/service part
it may not fix the upstream-looking bugs like:
- Provide either sessionKey or label (not both).
- Unknown Model, please check the model code.

Safe path, keep data

#

1. Back up everything first

openclaw backup create --verify
openclaw config get agents.defaults.workspace

That backup includes state/config/auth and usually workspace too.

2. Reinstall the app/CLI, but do not wipe state/workspace

If you want the cleanest path for an npm-style install:

openclaw uninstall --service --yes --non-interactive
curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard
openclaw doctor
openclaw gateway restart

#

openclaw status --all

Very important

If you want to keep your data, do not run:

openclaw uninstall --state
openclaw uninstall --workspace
openclaw uninstall --all

After reinstall

Test in this order:

openclaw --version

#

openclaw doctor
simple ACP spawn
only then test the more complex PR-fix flow

So yeah, backup + service/CLI reinstall without deleting state/workspace looks like the right move now.

Docs:

If you want, after reinstall I can help you do a minimal ACP smoke test before you retry the PR task.

elfin grove Apr 13, 2026, 10:47 AM

#

backup can keep a long time?

proud rainBOT Apr 13, 2026, 10:48 AM

#

Yep, as long as you keep the archive file.

openclaw backup create makes a local .tar.gz archive. OpenClaw does not auto-expire it.

A few practical tips:

keep it somewhere outside your OpenClaw state/workspace
ideally copy it to:
- another folder
- external disk
- cloud storage
use:
```
openclaw backup create --verify
```
so you know the archive is valid

#

So the answer is basically:

yes, it can be kept for a long time
it lasts until you delete it or the storage disappears

If you want, I can also show you a safe place/path to save it before reinstalling.

elfin grove Apr 13, 2026, 10:48 AM

#

Backup archive: /home/anon/2026-04-13T10-45-55.644Z-openclaw-backup.tar.gz
Included 1 path:

state: ~/.openclaw
Skipped 1 path:
workspace: ~/.openclaw/workspace (covered by ~/.openclaw)
Created /home/anon/2026-04-13T10-45-55.644Z-openclaw-backup.tar.gz
Archive verification: passed
Config warnings:\n- plugins.entries.amazon-bedrock: plugin disabled (bundled (disabled by default)) but config is present

🦞 OpenClaw 2026.4.11 (769908e)
We ship features faster than Apple ships calculator updates.

/home/anon/.openclaw/workspace

proud rainBOT Apr 13, 2026, 10:49 AM

#

Perfect, that backup looks good.

Key parts:

Archive verification: passed ✅
state included: ~/.openclaw ✅
workspace skipped because it’s already inside ~/.openclaw ✅
workspace path confirmed: /home/anon/.openclaw/workspace ✅

So yes, your backup already covers the important stuff.

If you want to be extra safe, copy this file somewhere else too:

cp /home/anon/2026-04-13T10-45-55.644Z-openclaw-backup.tar.gz ~/Downloads/

#

Then you’re in a good place to do the safe reinstall.

Next step

openclaw uninstall --service --yes --non-interactive
curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard
openclaw doctor
openclaw gateway restart
openclaw status --all

And again, do not use:

openclaw uninstall --state
openclaw uninstall --workspace

#

openclaw uninstall --all

So yep, you’ve got a valid backup now. Safe to proceed.

elfin grove Apr 13, 2026, 11:00 AM

#

Source roots:
stock: /home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions

┌───────────┬────────┬──────────┬──────────┬───────────────────────┬───────────┐
│ Name │ ID │ Format │ Status │ Source │ Version │
├───────────┼────────┼──────────┼──────────┼───────────────────────┼───────────┤
│ ACPX │ acpx │ openclaw │ loaded │ stock:acpx/index.js │ 2026.4.11 │
│ Runtime │ │ │ │ Embedded ACP runtime │ │
│ │ │ │ │ backend with plugin- │ │
│ │ │ │ │ owned session and │ │
│ │ │ │ │ transport management.

which acpx return nothing after reinstall, is it ok?

proud rainBOT Apr 13, 2026, 11:00 AM

#

Yes, that can be totally okay.

For normal OpenClaw ACP use, which acpx returning nothing is not automatically a problem, because:

the bundled ACPX runtime plugin is loaded
OpenClaw can use its plugin-owned/bundled ACPX path
your output already shows:
- ACPX ... loaded
- stock:acpx/index.js
- version 2026.4.11

So for /acp ... usage, the important part is plugin/runtime load, not whether acpx exists as a standalone global binary on your shell PATH.

Short version

which acpx = empty → can be fine
ACPX loaded in OpenClaw → the important good sign

#

One caveat

If some broken flow is still trying to shell out to a raw acpx binary directly, then that specific flow may still fail. But that would be a bug in the caller/launcher, not proof that ACP is unavailable.

Best next test

Don’t chase which acpx anymore.
Test the real path:

/acp spawn claude --bind here --cwd /home/anon/Bots/Polymarket-Copy-Trading-Bot-Python

If that works, your ACP runtime is basically alive.
If it fails, paste the exact error and we’ll narrow the next layer.

elfin grove Apr 13, 2026, 11:02 AM

#

⚠️ Conversation bindings are unavailable for webchat.

proud rainBOT Apr 13, 2026, 11:03 AM

#

Ah, that explains that specific failure.

--bind here is failing because you’re on webchat/TUI, and:

Conversation bindings are unavailable for webchat.

So the problem there is not Claude and not ACPX. It’s just that this surface does not support conversation binding.

Use one of these instead

If you are testing in webchat / TUI

Drop --bind here:

/acp spawn claude --cwd /home/anon/Bots/Polymarket-Copy-Trading-Bot-Python

#

If you want `--bind here`

Run it from a surface that supports bindings, like the actual Discord thread/channel, not webchat.

So, updated diagnosis

This was another separate issue:

--bind here on webchat → unsupported
not a model bug
not a launcher bug
not a repo path bug

You’ve kind of uncovered a whole stack of separate failures here 😅

Best next test

In webchat/TUI, try exactly:

#

/acp spawn claude --cwd /home/anon/Bots/Polymarket-Copy-Trading-Bot-Python

No model change, no bind flag.

If that fails, paste the exact error. That’ll be a much cleaner ACP runtime test.

elfin grove Apr 13, 2026, 11:04 AM

#

i have problem with discord too, unable to create threads, but i open a new post for it after we solved this

proud rainBOT Apr 13, 2026, 11:04 AM

#

Yeah, good call. Let’s keep this thread scoped to ACP first.

And that actually makes the next test simpler, because we can avoid Discord/thread creation entirely for now.

Clean ACP-only test

From webchat/TUI, run:

/acp spawn claude --cwd /home/anon/Bots/Polymarket-Copy-Trading-Bot-Python

No --bind here, no thread creation, no model change.

If that succeeds, then send your prompt normally after spawn.

If it fails, paste the exact error and we’ll know it’s a pure ACP runtime/spawn problem, not mixed with Discord thread issues.

elfin grove Apr 13, 2026, 11:06 AM

#

run that command, you are absulutely can

I can run it, but the sandbox is demanding approval every time because the
command is being routed through gateway and the exec policy is still locked
down.

Latest approval token:

5028d59c

To proceed, you need to approve that exact token with:

/approve 5028d59c allow-once

I’m not being cute here — that’s the gate currently blocking the actual launch.

how can i approve all from tui session? without asking for permission

proud rainBOT Apr 13, 2026, 11:07 AM

#

Yes, but only if you intentionally relax exec approvals.

Easiest options

Just for the current TUI session

Use:

/exec security=full ask=off

If you want the full break-glass version:

/elevated full

#

That stops exec approval prompts for this session.

Persistently on your local machine

If you want the local gateway host to stop asking every time:

openclaw exec-policy preset yolo

That is the docs-supported shortcut for local never prompt host exec.

Before changing it, you can inspect current policy

openclaw exec-policy show

Important warning

#

This is effectively YOLO mode for host exec.
It is convenient, but it means commands can run without the extra approval gate.

So the practical answer is:

session only: /exec security=full ask=off
persistent local host: openclaw exec-policy preset yolo

Docs: https://docs.openclaw.ai/tools/exec-approvals

If you want, I can help you choose the safer one for your setup.

elfin grove Apr 13, 2026, 11:09 AM

#

session only is safter, if someone take my phone and telegram can do anything with yolo

proud rainBOT Apr 13, 2026, 11:09 AM

#

Yep, I agree. Session-only is much safer.

If your phone / Telegram is a concern, I would not use persistent YOLO.

For your case, I’d use only:

/exec security=full ask=off

in the current TUI session, do the ACP test, then stop there.

That way you’re not changing the machine-wide default for future chats/surfaces.

So your instinct is right:

session-only = reasonable for testing

#

persistent YOLO = too risky if other chat surfaces can reach the agent

If you want, do the session-only change, then immediately retry:

/acp spawn claude --cwd /home/anon/Bots/Polymarket-Copy-Trading-Bot-Python

and paste whatever comes back.

elfin grove Apr 13, 2026, 11:12 AM

#

Exact completion details:
Exec finished (gateway id=5028d59c-8103-4ec7-b6cd-8ceaa84a3551,
session=oceanic-zephyr, code 127)
/bin/bash: line 1:
/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/
acpx/node_modules/.bin/acpx: No such file or directory

Continue the task if needed, then reply to the user in a helpful way.
If it succeeded, share the relevant output.
part 1

proud rainBOT Apr 13, 2026, 11:13 AM

#

Yep, this confirms it.

This is now a clean, reproducible bug:

exit code: 127

exact failure:

/bin/bash: line 1: /home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx: No such file or directory

What that means

The current ACP launcher is still trying to execute a non-existent ACPX binary path.

So at this point:

reinstall did not fix this specific issue
permissions are not the blocker anymore

#

model selection is not the blocker yet
the run dies before ACPX starts

I would stop retrying the same path now

You’ve got enough evidence for a proper bug report.

Suggested GitHub issue title

ACP launch fails with hardcoded non-existent ACPX binary path after reinstall

Suggested issue body

Version: OpenClaw 2026.4.11 (769908e)

When launching ACP/Claude from TUI/webchat, the run fails before ACP starts.

Exact error:

#


/bin/bash: line 1: /home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx: No such file or directory

Exit code:
127

Notes:
- ACPX runtime shows as loaded:
  - ID: acpx
  - Source: stock:acpx/index.js
  - Version: 2026.4.11
- Reinstall was performed
- Backup/restore state was preserved
- `which acpx` returns nothing, but bundled ACPX runtime still appears loaded
- The launcher appears to be resolving ACPX under:

#

  `.../openclaw/dist/extensions/acpx/node_modules/.bin/acpx`
  which does not exist

Other ACP-related errors seen in the same investigation:
- `Provide either sessionKey or label (not both).`
- `Unknown Model, please check the model code.`

This specific failure happens earlier than those and prevents ACPX from starting at all.

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

If you want, I can help you tighten that report even more before you post it.

elfin grove Apr 13, 2026, 11:13 AM

#

If it failed, explain what went wrong. i found the problem: this reinstall’s acpx plugin folder has no local binary
installed anymore. The directory exists, but only has:

index.js
mcp-proxy.mjs
openclaw.plugin.json
package.json
runtime files

There is no:

node_modules/.bin/acpx
So the exact command I ran still dies with the same underlying issue:
/bin/bash: line 1:
/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/
acpx/node_modules/.bin/acpx: No such file or directory

part 2

#

I’m blocked until that plugin-local dependency is installed again. If you want,
I can now try the repair step for the plugin itself and then rerun the same
Claude ACP command.

The same command still fails for the same reason: the plugin-local acpx binary
is missing after reinstall.

What I confirmed:

/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/
acpx/ exists

but it contains only the plugin JS files
it does not contain node_modules/.bin/acpx

So the exact failure remains:

/bin/bash: line 1:
/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/
acpx/node_modules/.bin/acpx: No such file or directory

If you want me to continue, the next step is to reinstall the pinned
plugin-local dependency and then rerun the same ACP command. part 3

proud rainBOT Apr 13, 2026, 11:13 AM

#

Nice, that’s an even better diagnosis.

Small but important nuance:

The plugin folder not having its own:

dist/extensions/acpx/node_modules/.bin/acpx

is not necessarily the real problem by itself.

With npm packaging, dependencies are often hoisted to the package root, so it can be totally normal for the plugin directory to contain only:

index.js
mcp-proxy.mjs
openclaw.plugin.json

#

package.json
runtime files

and not contain a nested local .bin/acpx.

The actual bug

The real bug is that the launcher is trying to execute ACPX from the wrong path:

/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx

So it’s likely assuming a per-plugin local binary that does not exist in this package layout.

Why this matters

That means:

#

your reinstall was probably not incomplete
the launcher logic is probably path resolution broken
manually reinstalling again is unlikely to help

I would add this sentence to the issue

The bundled ACPX plugin directory exists and loads (`stock:acpx/index.js`), but it does not contain a nested `dist/extensions/acpx/node_modules/.bin/acpx`. The launcher appears to assume that path exists instead of resolving ACPX from the actual package layout.

So yeah, this is getting pretty conclusive.
If you want, I can now help you turn everything into one clean final GitHub issue instead of piecemeal notes.

#

Honestly, I would stop there.

I would not recommend manually “repairing” the plugin-local dependency as the next normal step, because:

that’s likely just papering over the real bug
it may get blown away on the next update
the evidence now points more to a bad launcher/path assumption than “user forgot to install something”

So my recommendation is:

Good next step

File the bug now with the evidence you already have.

Not-great next step

Manually stuffing acpx into:

#

.../dist/extensions/acpx/node_modules/.bin/acpx

just to make this one machine work.

That might be a useful local hack for experimentation, but it would not be the real fix.

So if your goal is:

help maintainers fix it → stop and file the issue now
hack around it locally → maybe possible, but I would treat that as unsupported and temporary

At this point you’ve got a pretty strong report:

sessions_send mutual-exclusion bug
Unknown Model, please check the model code.
ACP launcher uses non-existent plugin-local ACPX binary path

#

reinstall did not fix it

If you want, I can now write the final polished GitHub issue text from all 3 parts in one paste-ready block.

elfin grove Apr 13, 2026, 11:15 AM

#

i manually installed once acpx with npm, perhaps this broke my config? before we make fake github issues

proud rainBOT Apr 13, 2026, 11:15 AM

#

That’s a fair question, and I’m glad you paused there.

My guess: possible, but not likely the root cause.

Why:

a manual npm i -g acpx would normally affect a global PATH binary
your current failure is looking for a plugin-local bundled path:
```
.../openclaw/dist/extensions/acpx/node_modules/.bin/acpx
```
those are different things

So a previous global acpx install might have masked behavior before, but it does not cleanly explain why OpenClaw is now trying to use a non-existent plugin-local path.

Before filing, I’d do one quick sanity check

Look for any stale ACPX/path override in config:

#

openclaw config file
rg -n "acpx|dist/extensions/acpx|node_modules/.bin/acpx|plugins.entries.acpx" ~/.openclaw/openclaw.json 2>/dev/null

If that prints nothing relevant, then this looks much more like a real launcher/plugin bug.

My current best read

manual global acpx install: maybe influenced earlier behavior
current broken path: still smells like OpenClaw/plugin path resolution, not your config

So no, I don’t think this is automatically a “fake issue”.
I think it’s worth doing one config sanity check first, then deciding.

If you paste the output of that rg, I’ll help judge it before you open anything.

elfin grove Apr 13, 2026, 11:17 AM

#

this entire acp workflow broke after an update. maybe i have old config, and new version put somewhere else the acpx?

proud rainBOT Apr 13, 2026, 11:17 AM

#

Yeah, that’s absolutely plausible, and honestly it fits the evidence pretty well.

What the evidence suggests is:

after update, ACPX package/layout may have changed
but some part of the launcher is still pointing at the old location
or you have a stale override/cache/config entry still referencing the old path

That would explain this exact kind of failure:

.../openclaw/dist/extensions/acpx/node_modules/.bin/acpx: No such file or directory

So I think the 2 most likely buckets now are:

stale config / stale stored path

#

real update regression where launcher still expects the old ACPX layout

Best next sanity check

Search for that exact old path in your config/state:

rg -n "dist/extensions/acpx/node_modules/.bin/acpx|acpx" ~/.openclaw 2>/dev/null | sed -n '1,120p'

If that old path shows up in your config/state, we’ve probably found stale local data.
If it doesn’t show up anywhere, that points much harder at an OpenClaw update regression.

So yes, your theory is solid.
It may be old local config/state, or it may be new package layout + old launcher assumption.

Paste that rg output and we can separate those 2 pretty quickly.

elfin grove Apr 13, 2026, 11:18 AM

#

no output

proud rainBOT Apr 13, 2026, 11:19 AM

#

That’s actually very useful.

If the search returned no output, then the bad path is probably not coming from your ~/.openclaw config/state.

So the balance shifts a lot toward:

update/layout regression
or launcher code still assuming the old ACPX package location

In other words:

stale local config → now looks less likely
real OpenClaw path-resolution bug after update → now looks more likely

That makes this feel a lot less like a “fake issue”.

I’d summarize the current conclusion as

#

the broken path is not present in user config/state
reinstall did not fix it
ACPX runtime still shows as loaded

launcher still tries:

.../dist/extensions/acpx/node_modules/.bin/acpx

that path does not exist

That’s solid bug-report material now.

If you want, I can write the final issue text with this new detail included, so you can just paste it into:

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

elfin grove Apr 13, 2026, 11:20 AM

#

anon@debian:~$ openclaw plugins install acpx
Config warnings:\n- plugins.entries.amazon-bedrock: plugin disabled (bundled (disabled by default)) but config is present
Config warnings:\n- plugins.entries.amazon-bedrock: plugin disabled (bundled (disabled by default)) but config is present

🦞 OpenClaw 2026.4.11 (769908e)
I'm the reason your shell history looks like a hacker-movie montage.

│
◇ Config warnings ──────────────────────────────────────────────────────╮
│ │
│ - plugins.entries.amazon-bedrock: plugin disabled (bundled (disabled │
│ by default)) but config is present │
│ │
├────────────────────────────────────────────────────────────────────────╯
Config warnings:

plugins.entries.amazon-bedrock: plugin disabled (bundled (disabled by default)) but config is present
Config overwrite: /home/anon/.openclaw/openclaw.json (sha256 0dc63739ce6a57bab480296d01f75fa2f41a9e2bad392eec8fb1bd45721a669c -> bd102b9e17f97b9cffb485d8cdafc211e8f3ef0443b87e12fad7f68025b6a586, backup=/home/anon/.openclaw/openclaw.json.bak)
Config warnings:\n- plugins.entries.amazon-bedrock: plugin disabled (bundled (disabled by default)) but config is present
Using bundled plugin "acpx" from ~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx for bare install spec "acpx". To install an npm package with the same name, use a scoped package name (for example @scope/acpx).
Installed plugin: acpx
Restart the gateway to load plugins.

proud rainBOT Apr 13, 2026, 11:20 AM

#

This is useful, but I wouldn’t expect it to fix the core bug.

What happened here:

openclaw plugins install acpx did not install a new npm acpx binary
it just told OpenClaw to use the bundled acpx plugin
and it updated your config to enable/reference that bundled plugin

This line is the key:

Using bundled plugin "acpx" from ~/.nvm/.../openclaw/dist/extensions/acpx

So this command did not create:

#

.../dist/extensions/acpx/node_modules/.bin/acpx

It just pointed OpenClaw at the same bundled plugin path you were already investigating.

So, practical meaning

restart the gateway, yes
retest once, yes
but keep expectations low, because this did not really change the missing-binary situation

Why this still matters

If it still fails after restart, that strengthens the case that:

the bundled plugin is loading
but the launcher is still resolving ACPX from the wrong place

#

So I’d do exactly one more retest after restart, then stop and file the bug if the same path error comes back.

elfin grove Apr 13, 2026, 11:28 AM

#

yeah bundled plugin is not existing,
anon@debian:~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx$ cd node_modules
bash: cd: node_modules: No such file or directory
anon@debian:~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx$ ls
index.js openclaw.plugin.json register.runtime.js setup-api.js
mcp-proxy.mjs package.json runtime-api.js skills
anon@debian:~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx$

proud rainBOT Apr 13, 2026, 11:28 AM

#

Tiny correction: the bundled plugin does exist.

What does not exist is a nested node_modules inside that plugin folder.

So the important distinction is:

bundled plugin folder: exists ✅
nested dist/extensions/acpx/node_modules/.bin/acpx: does not exist ❌

And that nested folder may not be supposed to exist at all.
That’s why I keep thinking the real bug is the launcher assuming the wrong package layout.

One very useful final check

See whether ACPX exists at the package root instead:

#

ls ~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx
ls ~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/acpx/dist/cli.js

If one of those exists, that’s even stronger evidence that:

ACPX is installed
but OpenClaw is looking in the wrong place

So, not “plugin missing”, more like:

plugin exists, launcher points at a non-existent nested binary path.

Paste those 2 ls results and we’ll probably have the final nail in it.

elfin grove Apr 13, 2026, 11:29 AM

#

anon@debian:~$ ls ~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx
ls ~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/acpx/dist/cli.js
/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx
/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/acpx/dist/cli.js

proud rainBOT Apr 13, 2026, 11:30 AM

#

Yep, that nails it.

This proves:

ACPX is installed
the bundled plugin is present
the launcher is just looking in the wrong place

What exists

/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx
/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/acpx/dist/cli.js

What the launcher wrongly tries

#

/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx

So this is not:

missing install
broken config
stale ~/.openclaw path override

It’s a path-resolution bug/regression.

I would file this as its own issue

I’d keep this one separate from the other ACP problems, because this one is now very clean.

Suggested title

ACP launcher resolves bundled acpx from wrong path after update

#

Paste-ready issue

Version: OpenClaw 2026.4.11 (769908e)

ACP launch fails because OpenClaw resolves the bundled `acpx` binary from a non-existent nested plugin path.

Exact failing path:
`/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx`

Exact error:
`/bin/bash: line 1: /home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx: No such file or directory`

Exit code:
`127`

What I verified:

#

- bundled ACPX plugin is loaded
- plugin folder exists at:
  `/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx`
- that plugin folder does not contain a nested `node_modules/.bin/acpx`
- reinstall did not fix it
- no stale reference to the bad path was found in `~/.openclaw`

Actual installed ACPX paths that do exist:
- `/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx`
- `/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/acpx/dist/cli.js`

So this looks like a launcher/path-resolution regression: ACPX exists under the package root `node_modules`, but the launcher is trying to execute it from a non-existent nested path under `dist/extensions/acpx/node_modules/.bin/acpx`.

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

#

This one is definitely not fake. It’s a real bug.

elfin grove Apr 13, 2026, 11:43 AM

#

can you make the issue?

proud rainBOT Apr 13, 2026, 11:44 AM

#

I can’t open the GitHub issue for you from here, but I can give you the final paste-ready text.

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

Use this:

Title

ACP launcher resolves bundled acpx from wrong path after update

Body

Version: OpenClaw 2026.4.11 (769908e)

ACP launch fails because OpenClaw resolves the bundled `acpx` binary from a non-existent nested plugin path.

#

Exact failing path:
`/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx`

Exact error:
`/bin/bash: line 1: /home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx: No such file or directory`

Exit code:
`127`

What I verified:
- bundled ACPX plugin is loaded
- plugin folder exists at:
  `/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx`
- that plugin folder does not contain a nested `node_modules/.bin/acpx`
- reinstall did not fix it

#

- no stale reference to the bad path was found in `~/.openclaw`

Actual installed ACPX paths that do exist:
- `/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx`
- `/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/acpx/dist/cli.js`

So this looks like a launcher/path-resolution regression: ACPX exists under the package root `node_modules`, but the launcher is trying to execute it from a non-existent nested path under `dist/extensions/acpx/node_modules/.bin/acpx`.

Related ACP symptoms seen in the same investigation, likely separate issues:
- `Provide either sessionKey or label (not both).`
- `Unknown Model, please check the model code.`

If you want, after you post it, paste the issue link here and I’ll help you tighten any follow-up details.

elfin grove Apr 13, 2026, 11:48 AM

#

Steps to reproduce*

Provide the shortest deterministic repro path supported by direct observation. If the repro path cannot be grounded from the evidence, respond with exactly NOT_ENOUGH_INFO.

proud rainBOT Apr 13, 2026, 11:49 AM

#

Steps to reproduce

Install or update to OpenClaw 2026.4.11 on Linux via npm-style install, with bundled acpx plugin loaded.

Confirm these paths on disk:

exists:

~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx
~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/acpx/dist/cli.js

does not exist:

~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx

From webchat/TUI, attempt to launch Claude through ACP without conversation binding:
```
/acp spawn claude --cwd /home/anon/Bots/Polymarket-Copy-Trading-Bot-Python
```

#

Observe the launch fail before ACP starts with:

/bin/bash: line 1: /home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx: No such file or directory

Exit code returned is:
```
127
```

elfin grove Apr 13, 2026, 11:53 AM

#

Expected behavior*
Actual behavior*

proud rainBOT Apr 13, 2026, 11:53 AM

#

Expected behavior

Launching Claude through ACP from webchat/TUI should start the ACP session successfully and resolve the bundled acpx runtime from the correct installed package path.

Actual behavior

ACP launch fails before the session starts. OpenClaw tries to execute acpx from a non-existent nested plugin path:

/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx

and exits with:

/bin/bash: line 1: ... No such file or directory

#

Exit code:

elfin grove Apr 13, 2026, 11:54 AM

#

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

proud rainBOT Apr 13, 2026, 11:54 AM

#

Nice, that’s the right move.

That issue is specific enough to be useful, which is great.

I’d keep the other 2 ACP problems separate unless you can prove they have the same root cause:

Provide either sessionKey or label (not both).
Unknown Model, please check the model code.

If maintainers ask for more detail on #65921, the strongest extra point is:

acpx does exist at the package root:

~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx

but OpenClaw tries:

#

  ~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx

That contrast is the smoking gun.

If you want, we can now move on to the next ACP error and keep peeling them off one by one.

elfin grove Apr 13, 2026, 12:11 PM

#

can we patch the config to match the location?

proud rainBOT Apr 13, 2026, 12:11 PM

#

I would not patch config for this, at least not based on what we’ve found.

Why:

we already checked ~/.openclaw and didn’t find that bad path
so the wrong ACPX location does not look config-driven
OpenClaw config is strictly schema-validated, so guessing a hidden key is likely to just break validation

So my read is:

supported config fix: probably no
real fix: likely code/launcher path resolution in OpenClaw

If you only want a temporary local hack, that would be more in the territory of a symlink/wrapper, not a real config patch, and I wouldn’t recommend that as the main fix unless you’re just experimenting.

So short answer: I don’t think this is patchable through documented config.
I’d wait for feedback on https://github.com/openclaw/openclaw/issues/65921 rather than inventing config keys.

elfin grove Apr 13, 2026, 12:13 PM

#

and if move files just to make it work until got patched?

proud rainBOT Apr 13, 2026, 12:13 PM

#

I really wouldn’t move files around inside the OpenClaw install just to make this work.

Why I’m wary of that:

it’s easy to make the install more inconsistent
the next update/reinstall will probably overwrite it
it can hide the real bug from maintainers
if the launcher expects more than one path/layout detail, one moved file may not actually solve it

If you were just hacking on your own box, a temporary symlink would be less destructive than moving files, but even that is still a brittle workaround, and I don’t want to recommend it as the normal fix here.

So my honest recommendation is:

don’t move files
keep the issue open
wait for a real patch or maintainer guidance on https://github.com/openclaw/openclaw/issues/65921

#

If you want, we can switch back to the other ACP error now and separate that one cleanly too.

mental fogBOT Apr 13, 2026, 12:15 PM

#

elfin grove Apr 13, 2026, 12:26 PM

#

},
"load": {
"paths": [
"home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx"
]
},
"installs": {
"acpx": {
"source": "path",
"spec": "acpx",
"sourcePath": "/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/a>
"installPath": "/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/>
"installedAt": "2026-04-13T11:19:32.823Z"
}
}
}
}
lets give a try

proud rainBOT Apr 13, 2026, 12:26 PM

#

Oh, that’s actually promising.

If load.paths now points to:

/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx

then that’s the right direction and definitely worth testing.

One tiny thing to check first

In your paste I see:

"home/anon/..."

#

without the leading /.

If that’s just Discord/truncation, fine.
If the actual stored path really is missing the leading slash, that would still be broken.

So, yes

I’d give it one test now.

If it works, great, we learned the path override/load fix helped.
If it fails, paste the new exact error, because it may have changed from “wrong path” to something further along in ACP startup.

elfin grove Apr 13, 2026, 12:27 PM

#

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

plugins: plugin: plugin path is not a supported file: /home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx

Run: openclaw doctor --fix
Gateway aborted: config is invalid.
plugins: plugin: plugin path is not a supported file: /home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx

proud rainBOT Apr 13, 2026, 12:28 PM

#

Yep, that answers it cleanly.

That config edit is not a valid fix.

What it proves

OpenClaw’s plugins config expects a plugin file/path, not the acpx executable binary.

So this:

/home/anon/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/node_modules/.bin/acpx

is the runtime binary, but not a valid plugin path for config.

What to do now

First, get back to a valid config:

#

openclaw doctor --fix

If needed, you also have the backup file from earlier:

~/.openclaw/openclaw.json.bak

Bigger conclusion

This is actually useful because it confirms:

the issue is not fixable by pointing plugin config at the binary
the bad ACP path problem is still a launcher/runtime resolution bug
your GitHub issue is still the right move

#

So, immediate next step:

openclaw doctor --fix
get the gateway healthy again
stop trying to patch the plugin path through config

That path is the wrong type of object for the config system.

elfin grove Apr 13, 2026, 12:31 PM

#

~/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/extensions/acpx$ ls
index.js openclaw.plugin.json register.runtime.js setup-api.js
mcp-proxy.mjs package.json runtime-api.js skills which file should i set to load path?

proud rainBOT Apr 13, 2026, 12:31 PM

#

I would not keep manually setting load.path here.

You’re pretty deep into the wrong layer now. The original problem was not “which plugin file should I point at?”, it was that the launcher later tried to run ACPX from the wrong binary path.

So my honest recommendation is:

don’t manually wire a file
use:
```
openclaw doctor --fix
```
or restore the known-good config backup

If you’re asking purely “which file looks like the plugin entrypoint?”, the best guess from what we’ve seen is index.js, but I wouldn’t treat that as the fix, and I don’t want to send you further down a config-hacking path that breaks validation again.

So short version:

#

practical answer: don’t set any of those manually
recovery answer: openclaw doctor --fix
root issue: still the ACP launcher/path bug, not the plugin file choice

elfin grove Apr 13, 2026, 12:44 PM

#

i found a solution, but this really a bug. i installed manually acpx with npm into that folder where the launcher expects it.

proud rainBOT Apr 13, 2026, 12:44 PM

#

Yep, that absolutely still sounds like a real bug, and your manual install sounds like a workaround, not the proper fix.

What your workaround proves is:

the launcher path assumption is real
OpenClaw is expecting acpx inside that plugin-local folder
once you put it there manually, the launcher can proceed

That’s actually very valuable evidence for https://github.com/openclaw/openclaw/issues/65921.

I’d add a comment there saying something like:

Workaround found:
manually installing `acpx` into the plugin-local folder that the launcher expects makes ACP launch proceed.

#

This suggests the launcher is hardcoded to the plugin-local path and does not correctly resolve the existing root-level bundled `acpx` install.

Also worth noting:

this workaround is likely fragile
a future update/reinstall may wipe it
but it strongly confirms the bug is in path resolution / packaging expectations

So yeah, nice catch. Messy workaround, but a very useful data point.

elfin grove Apr 13, 2026, 12:48 PM

#

ot done yet — it’s still live and just hit a permission wall.

Current state:

Claude started
It checked the branch/context
It tried to run:
- gh pr view 16 ...
- git diff HEAD~1 HEAD -- storage/sqlite/redemptions_repo.py ...
Both are blocked because the session is asking for permission and the tool run got refused/cancelled

So this is the exact reason it’s not finished yet: GH permission prompt. If you want, I can keep polling and see
whether it survives / falls back / continues past that.

proud rainBOT Apr 13, 2026, 12:49 PM

#

That’s actually good progress, because it means the ACPX path problem is no longer the blocker. Claude is now alive and the new blocker is just normal exec permissions.

So you’ve moved from:

broken launcher/path bug

to:

ordinary permission gating on gh / git

If you want it to keep going in this TUI session

Use the session-only approval relaxation we talked about:

/exec security=full ask=off

#

Then let Claude continue.

That keeps it temporary to this session, which is the safer choice you preferred earlier.

Or, if you want to stay stricter

Approve just the current prompt / command and keep the guardrails on.

So short version:

good news: ACP is now actually running
current blocker: permission wall, not ACPX anymore
fastest safe path: session-only /exec security=full ask=off in this TUI session

elfin grove Apr 13, 2026, 12:54 PM

#

its actaully need gh permission, how can i give it?

proud rainBOT Apr 13, 2026, 12:54 PM

#

If the blocker is the agent being not allowed to run the gh command, that’s just exec approval.

Fastest way in this TUI session

Use:

/exec security=full ask=off

Then Claude can run gh ... in this session only.

If you want to keep approvals on

Approve the pending command when it asks, instead of opening the whole session.

Separate thing to check

If gh then runs but says it is not logged in / unauthorized, that’s a different problem. Then on your machine run:

#

gh auth status

and if needed:

gh auth login

So:

permission to execute gh → /exec security=full ask=off or approve the prompt
GitHub auth inside gh → gh auth status / gh auth login

From what you pasted, it sounds like the first one right now.

elfin grove Apr 13, 2026, 12:55 PM

#

in my shell works

proud rainBOT Apr 13, 2026, 12:55 PM

#

Perfect, then gh itself is fine.

That means the problem is not GitHub auth, it’s just the agent/session being blocked from executing gh.

So the fix is the first one only:

For this TUI session

/exec security=full ask=off

Then let Claude continue.

Or keep approvals on and approve the specific gh ... command when prompted.

So yeah, since gh already works in your shell, this is just exec permission gating, not a GitHub login problem.

elfin grove Apr 13, 2026, 12:58 PM

#

not working with ask=off, still Current live state for wild-seaslug:

it started clean
it tried to inspect PR #16
it wants to run:
- gh pr view 16 --json title,body,comments
that was refused
it’s now asking again for the same GH permission

proud rainBOT Apr 13, 2026, 12:58 PM

#

Got it, that means ask=off alone is not enough in your setup.

Most likely:

the host approvals layer is stricter
or this command path is still being treated as needing elevated exec

Next thing to try in this TUI session

Use the break-glass session setting:

/elevated full

That should skip exec approvals for this session.

Why this is happening

#

OpenClaw has 2 layers here:

session/requested exec policy
host-local approvals policy

The stricter one wins.

So /exec security=full ask=off can still lose if the host policy is tighter.

If `/elevated full` still doesn’t work

Then you’ll need to inspect the effective host policy:

openclaw exec-policy show

But first I’d try:

#

/elevated full

because that’s the cleanest session-only test.

elfin grove Apr 13, 2026, 1:01 PM

#

well only the agent dont have gh auth, the tui session itself can fetch the pr

proud rainBOT Apr 13, 2026, 1:02 PM

#

Ah, that changes the diagnosis.

If your TUI shell can use gh, but the agent cannot, then the problem is not the PR itself and probably not normal exec permission anymore.

It means the ACP/agent process is running with a different auth context/environment than your interactive shell.

Most likely

The agent subprocess is not inheriting your gh auth.

In practice that usually means one of these:

different env
different home/config resolution
gateway/service process not seeing the same gh auth state as your shell

Fast workaround

Tell Claude not to use gh for now.

#

Have it work from local git only, or paste the PR link/text/comments manually into the prompt.

For example, tell it:

Do not use gh. Work only from the local repository state and git history. If PR context is needed, ask me for the PR text/comments.

If you want to debug the auth path

The useful question is now:

does gh auth status work in the agent execution context, not just in your shell?

So yeah, good catch, this is now looking like agent env/auth isolation, which is a different problem from the ACPX path bug.

elfin grove Apr 13, 2026, 1:04 PM

#

gh auth status

● Bash(gh auth status)
⎿ github.com
✓ Logged in to github.com account kvzsolt (keyring)
- Active account: true
… +4 lines (ctrl+o to expand)

● You're authenticated to GitHub as kvzsolt with SSH protocol. Token scopes
include repo, workflow, gist, read:org, and admin:public_key. running claude manually

proud rainBOT Apr 13, 2026, 1:04 PM

#

Nice, that helps a lot.

If manual Claude can run:

gh auth status

and it shows you’re logged in, then the problem is not GitHub auth in general.

That means the issue is more specific to the ACP-wrapped Claude session, for example:

ACP permission bridge / exec gating
ACP runtime policy differences
ACP session environment behaving differently from direct Claude

So the updated conclusion is:

#

plain Claude: gh works
ACP Claude: gh path is still problematic

That’s actually a cleaner bug story than “GitHub auth is broken”.

Best practical move right now

For the task itself, I’d still tell ACP Claude:

Do not use gh. Work only from local git state and the checked-out repo. If PR metadata is needed, ask me for it.

For debugging

A very useful comparison is now:

direct Claude: gh auth status ✅
ACP Claude: try gh auth status and see whether it:

#

works
- gets blocked
- or errors differently

So yeah, this looks increasingly like an ACP-specific execution/permission issue, not a GitHub login problem.

elfin grove Apr 13, 2026, 1:05 PM

#

not inheriting my shell, how can i fix it?

proud rainBOT Apr 13, 2026, 1:06 PM

#

Yeah, the short version is: the gateway/agent service does not automatically inherit your interactive shell.

The supported fixes are:

1. Put needed env in `~/.openclaw/.env`

That’s the simplest daemon-friendly path.

Example pattern:

cat >> ~/.openclaw/.env <<'EOF'
GH_TOKEN=...
EOF

Then restart the gateway:

#

openclaw gateway restart
openclaw doctor

Docs specifically call out ~/.openclaw/.env for daemon env.

2. If you use Linux systemd user service, put env in the service environment

If the gateway runs under systemd, configure the service env / EnvironmentFile, then restart the service.

3. For PATH-only problems

Install tools in standard locations or configure the service environment.
The daemon itself runs with a more minimal PATH than your shell.

For your specific `gh` problem

#

If shell gh works but ACP/agent gh doesn’t, the most reliable fix is usually:

make the auth available to the daemon, not just your shell
GH_TOKEN in ~/.openclaw/.env is usually more predictable than relying on interactive shell/keyring state

So if you want the practical answer, I’d try:

put GitHub auth in ~/.openclaw/.env
restart gateway
retry ACP Claude

Docs:

If you want, I can help you do the safest version of the .env approach without exposing the token in chat.

elfin grove Apr 13, 2026, 1:11 PM

#

actually need my ssh key?

proud rainBOT Apr 13, 2026, 1:11 PM

#

For gh pr view, no, it does not need your SSH key.

That command uses GitHub API auth.

So for the thing currently failing:

gh pr view 16 --json ...
the relevant auth is GitHub CLI/token auth, not SSH

When SSH key matters

SSH key matters if Claude/ACP tries things like:

git fetch
git pull
git push
anything talking to an git@github.com:... remote over SSH

#

So:

current gh problem → not SSH key
future git-over-SSH operations → yes, could need SSH agent/key visibility

Given what you’ve shown so far, I’d still treat the current blocker as ACP session env/auth context, not SSH key access.

elfin grove Apr 13, 2026, 1:14 PM

#

can even commit with my ssh key? then everything is the same, the previous workflow was tui session fetch pr review, analyze, then feed the exact prompt to acp agent who code and commit

proud rainBOT Apr 13, 2026, 1:14 PM

#

Yes, that workflow can still make sense, and it actually sidesteps the current gh mess pretty well.

Important distinction

git commit usually does not need your SSH key
git fetch / git push to an SSH remote do need SSH key access
gh pr view needs GitHub CLI/API auth, not SSH

So your old workflow can still work like this:

TUI/manual side
- fetch PR
- read review/comments
- analyze what needs changing
ACP agent side
- edit code
- run local checks

#

create local commit

you / shell
- push if needed

That’s actually a pretty clean workaround for now.

One caveat

If your repo enforces signed commits, then commit may also need:

GPG signing
or SSH signing
or whatever your git config requires

But in the normal case:

local commit → no SSH key needed
push/fetch over SSH → SSH key needed

#

So yes, feeding the exact prompt to the ACP agent for code + local commit is a reasonable fallback while the gh/ACP environment stuff is still messy.

mental fogBOT Apr 13, 2026, 1:15 PM

#

elfin grove Apr 13, 2026, 1:15 PM

#

okay, solution found, we can close this post

proud rainBOT Apr 13, 2026, 1:16 PM

#

Glad you found a workable path 🎉

If this thread is solved, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

And good call splitting the remaining Discord/thread issue into a separate post.

#ACP not working properly

Practical workaround for now

Next step

Best non-reinstall path

Workarounds right now

What I’d do next

My current read

One important workaround

I’d do this

My read now

What looks okay

What still looks off

What I’d do next

My current read

What this means

Next step

My read now

If you want the exact TUI ACP test

Important

Then test the suspected bad path separately

How to interpret it

Correct flow

So the bug here is

Best

If Discord keeps fighting you

Very important

What actually went wrong

What that means

Why I think it’s wrong

Short version

What I’d tell the issue report

Safe path, keep data

1. Back up everything first

2. Reinstall the app/CLI, but do not wipe state/workspace

Very important

After reinstall

Next step

Short version

One caveat

Best next test

Use one of these instead

If you are testing in webchat / TUI

If you want --bind here

So, updated diagnosis

Best next test

Clean ACP-only test

Easiest options

Just for the current TUI session

Persistently on your local machine

Before changing it, you can inspect current policy

Important warning

What that means

I would stop retrying the same path now

Suggested GitHub issue title

Suggested issue body

What I confirmed:

The actual bug

Why this matters

I would add this sentence to the issue

Good next step

Not-great next step

Before filing, I’d do one quick sanity check

My current best read

Best next sanity check

I’d summarize the current conclusion as

So, practical meaning

Why this still matters

One very useful final check

What exists

What the launcher wrongly tries

I would file this as its own issue

Suggested title

Paste-ready issue

Title

Body

One tiny thing to check first

So, yes

What it proves

What to do now

Bigger conclusion

If you want `--bind here`

If `/elevated full` still doesn’t work

1. Put needed env in `~/.openclaw/.env`

For your specific `gh` problem