ACP metadata is missing

[hidden roost]

I have configured acp on my client but when i enabled acpx i start sseeing ACP error (ACP_SESSION_INIT_FAILED): ACP metadata is missing for agent:standard:acp:c1b85bb8-66da-4f00-92cf-e35eb94001da. Recreate this ACP session with /acp spawn and rebind the thread.
next: If this session is stale, recreate it with /acp spawn and rebind the thread.acp entry in opencclao "acp": {
"enabled": true,
"backend": "acpx",
"defaultAgent": "standard",
"allowedAgents": [
"standard",
""
], and plugin entry look like this "acpx": {
"config": {
"permissionMode": "approve-all",
"pluginToolsMcpBridge": true,
"openClawToolsMcpBridge": true,
"agents": {
"standard": {
"command": "openclaw"
}
}
},......can some help configure acp and acpx on openclaw

[hallow saddle]

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

[real copper]

This error is usually not “bad ACPX config”; it means the Discord/thread binding is pointing at an ACP session key whose ACP metadata is gone or stale:

agent:standard:acp:c1b85bb8-66da-4f00-92cf-e35eb94001da

Do this first:

openclaw --version
openclaw status --all

Then in the same Discord thread/channel where you want ACP bound:

/acp doctor
/acp sessions

[real copper]

/acp close
/acp spawn <agent> --bind here

Use a real ACPX harness id for <agent>. Built-in ids include codex, claude, gemini, cursor, openclaw, etc. Your config uses standard, which only works if you defined a custom ACPX agent named standard. Also remove the empty string from allowedAgents; keep only actual agent ids.

A safer baseline config shape is:

{
  acp: {
    enabled: true,
    dispatch: { enabled: true },
    backend: "acpx",
    defaultAgent: "codex",

[real copper]

    allowedAgents: ["codex"]
  },
  plugins: {
    entries: {
      acpx: {
        enabled: true,
        config: {
          permissionMode: "approve-all",
          pluginToolsMcpBridge: true,
          openClawToolsMcpBridge: true
        }
      }
    }
  }
}

[real copper]

If you really want the custom standard alias, make sure its command launches an ACP-speaking harness. command: "openclaw" by itself is suspicious; for the OpenClaw ACP bridge, docs show commands like openclaw acp ..., and for normal coding harnesses it is easier to use the built-in codex / claude / gemini ids.

Docs:
https://docs.openclaw.ai/tools/acp-agents
https://docs.openclaw.ai/cli/acp
https://docs.openclaw.ai/start/faq

[hidden roost]

correction my acp entry fixed with "acp": {
"enabled": true,
"backend": "acpx",
"defaultAgent": "openclaw",

"allowedAgents": [
  "standard",
  ""
],
"maxConcurrentSessions": 4,
"dispatch": {
  "enabled": true
},
"stream": {
  "deliveryMode": "live"
}

}...ii have updated the plugin entry as below "acpx": {
"config": {
"permissionMode": "approve-all",
"pluginToolsMcpBridge": true,
"openClawToolsMcpBridge": true,
"agents": {
"openclaw": {
"command": "openclaw"
}
}
},
"enabled": true
}--

[real copper]

Thanks, that output helps. I see two concrete config problems:

1. acp.defaultAgent is openclaw, but acp.allowedAgents does not include openclaw. It has standard and an empty string. Remove the empty string and allow the actual ACPX harness id:

acp: {
  enabled: true,
  backend: "acpx",
  defaultAgent: "openclaw",
  allowedAgents: ["openclaw"],
  maxConcurrentSessions: 4,
  dispatch: { enabled: true },
  stream: { deliveryMode: "live" }
}

2. Your OpenClaw agent id is standard according to openclaw status --all. That is separate from the ACPX harness id. standard is your OpenClaw agent/session owner; openclaw, codex, claude, etc. are ACPX harness ids. Don’t put standard in acp.allowedAgents unless you also define an ACPX harness named standard.

[real copper]

For the plugin entry: I would remove this override first:

agents: {
  openclaw: { command: "openclaw" }
}

The built-in openclaw ACPX harness already exists. If you override it, the command needs to launch an ACP-speaking server; openclaw alone is likely wrong. The docs examples for OpenClaw ACP bridge use openclaw acp ..., not plain openclaw.

So use this simpler plugin config first:

plugins: {
  entries: {
    acpx: {

[real copper]

      enabled: true,
      config: {
        probeAgent: "openclaw",
        permissionMode: "approve-all",
        pluginToolsMcpBridge: true,
        openClawToolsMcpBridge: true
      }
    }
  }
}

Then restart the gateway and recreate the stale binding:

[real copper]

openclaw gateway restart

In the target chat/thread:

/acp doctor
/acp close
/acp spawn openclaw --bind here

If /acp doctor still fails, paste that output next. Docs for this exact surface: https://docs.openclaw.ai/tools/acp-agents and https://docs.openclaw.ai/cli/acp

[hidden roost]

----but on vscode when i connect openclaw agent ist create the sesin on agent:standard:acp:eddac37b-e39e-4553-94ef-49b6c589eb0e---
/acp doctor
ACP error (ACP_SESSION_INIT_FAILED): ACP metadata is missing for agent:standard:acp:eddac37b-e39e-4553-94ef-49b6c589eb0e. Recreate this ACP session with /acp spawn and rebind the thread.
next: If this session is stale, recreate it with /acp spawn and rebind the thread.

/acp close
ACP error (ACP_SESSION_INIT_FAILED): ACP metadata is missing for agent:standard:acp:eddac37b-e39e-4553-94ef-49b6c589eb0e. Recreate this ACP session with /acp spawn and rebind the thread.
next: If this session is stale, recreate it with /acp spawn and rebind the thread....how can reset my vscode acp client extension to use openclaw agent openclaw seeting in the acp client extensoion setting are "OpenClaw": {
"command": "npx",
"args": [
"openclaw",
"acp",

"--url",
"ws://127.0.0.1:18789

        ],--- but on the telegram if A K, [17 May 2026 at 18:34:43]:

/acp spawn openclaw --bind here

Anuj's openclaw AI, [17 May 2026 at 18:34:47]:
✅ Spawned ACP session agent:openclaw:acp:b7361c48-4977-4893-9501-5c0d463a08dd...

[real copper]

This is the key distinction:

openclaw acp in VSCode is ACP bridge mode. By default it creates an isolated Gateway session with an acp: key under your default OpenClaw agent, so you get:

agent:standard:acp:<uuid>

That is not the same thing as an ACPX harness session created by:

/acp spawn openclaw --bind here

which correctly created:

agent:openclaw:acp:b736...

So your VSCode extension is not “using the openclaw ACPX agent”; it is connecting to the OpenClaw ACP bridge and defaulting to the standard Gateway agent.

Fix the VSCode config by setting an explicit session.

[real copper]

For a normal VSCode-to-OpenClaw bridge session, use a non-acp: key:

"OpenClaw": {
  "command": "openclaw",
  "args": [
    "acp",
    "--url", "ws://127.0.0.1:18789",
    "--session", "agent:standard:vscode",
    "--reset-session"
  ]
}

If your gateway requires a token, add:

[real copper]

"--token-file", "/Users/anujsharma/.openclaw/gateway.token"

If you specifically want VSCode to attach to the Telegram-spawned ACPX harness session, target that exact existing session key instead:

"args": [
  "acp",
  "--url", "ws://127.0.0.1:18789",
  "--session", "agent:openclaw:acp:b7361c48-4977-4893-9501-5c0d463a08dd",
  "--require-existing"
]

But for most VSCode usage, I would use agent:standard:vscode. Then stop/restart the VSCode ACP client/extension so it drops the stale eddac37b... session. If the extension has a “clear sessions/reset agent” action, use that too.

[real copper]

Also: don’t test this by running /acp doctor inside the VSCode bridge session unless you intentionally attached to a real ACPX session. Test with a normal prompt first, or run /acp doctor from Telegram where the ACPX binding exists.

Docs: https://docs.openclaw.ai/cli/acp and https://docs.openclaw.ai/tools/acp-agents

[hidden roost]

after the config change it not connecting the acp agent with acp session id 2026-05-17T17:55:24.938Z] Using shell: /bin/zsh -l -c 'npx' 'openclaw' 'acp' '--url' 'ws://127.0.0.1:18789' '--session' 'agent:openclaw:acp:b7361c48-4977-4893-9501-5c0d463a08dd' '--require-existing'
[2026-05-17T17:55:24.939Z] ConnectionManager: connecting to agent agent_11
[2026-05-17T17:55:24.940Z] ConnectionManager: initializing connection to agent agent_11
[2026-05-17T17:55:29.143Z] ConnectionManager: initialized. Agent: openclaw-acp v2026.5.12
[2026-05-17T17:55:29.209Z] [OpenClaw stderr] Error handling request {
jsonrpc: '2.0',
id: 1,
method: 'session/new',
params: {
cwd: '/Users/anujsharma/.openclaw/workspace/Resume-Analyzer-AI',
mcpServers: []
}
} {
code: -32603,
message: 'Internal error',
data: { details: 'Agent "openclaw" no longer exists in configuration' }
}
[2026-05-17T17:55:29.209Z] ERROR: Failed to create session Internal error
RequestError: Internal error
at Tp.handleResponse (/Users/anujsharma/.vscode/extensions/formulahendry.acp-client-0.2.0/dist/extension.js:2:460500)
at Tp.processMessage (/U

[real copper]

That error is the important part:

Agent "openclaw" no longer exists in configuration

So VSCode is successfully starting openclaw acp, but the session key you gave it starts with:

agent:openclaw:...

In OpenClaw session keys, that first agent segment is an OpenClaw agent id, not just the ACPX harness name. Your openclaw status --all showed only one configured OpenClaw agent:

standard

So agent:openclaw:acp:b736... can’t be used by the bridge unless you also have an OpenClaw agent named openclaw in config.

For VSCode, use this instead:

[real copper]

"OpenClaw": {
  "command": "openclaw",
  "args": [
    "acp",
    "--url", "ws://127.0.0.1:18789",
    "--session", "agent:standard:vscode",
    "--reset-session"
  ]
}

Then fully restart the VSCode ACP client/extension.

Also: don’t use /acp doctor from that VSCode bridge session as the first test. That command is for ACPX harness sessions. Test with a normal prompt like “say hello and summarize current session”.

If your goal is specifically “VSCode should talk to the Telegram-spawned openclaw ACPX session”, then you need to either:

[real copper]

1. add an actual OpenClaw agent id named openclaw to agents.list, then restart gateway, or
2. recreate the ACPX workflow under your existing standard agent and target a agent:standard:... session key.

For now I’d recommend option 1 only if you really want a separate agent namespace. Otherwise keep VSCode on agent:standard:vscode; it is the clean bridge-mode setup.

Docs: https://docs.openclaw.ai/cli/acp

[hidden roost]

the issue i was facing was when i was sending approval from mv vscod ethey not being hounered and logs i would see -- am see ing this in logs on approva 17:47:33
info
exec approval followup dispatch failed (id=577fb2ce-c540-455e-b58d-62aa522785a2): Session followup failed: AcpRuntimeError: ACP metadata is missing for agent:standard:acp:1a63b463-a70e-4429-9309-ba7a47d30c87. Recreate this ACP session with /acp spawn and rebind the thread.: code=ACP_SESSION_INIT_FAILED
17:47:33
warn
exec approval followup dispatch failed (id=577fb2ce-c540-455e-b58d-62aa522785a2): Session followup failed: AcpRuntimeError: ACP metadata is missing for agent:standard:acp:1a63b463-a70e-4429-9309-ba7a47d30c87. Recreate this ACP session with /acp spawn and rebind the thread.: code=ACP_SESSION_INIT_FAILED

[real copper]

Yep, that log matches the same root cause.

Your approval is being resolved, but the follow-up is trying to wake this session:

agent:standard:acp:1a63b463-a70e-4429-9309-ba7a47d30c87

Because the key contains :acp:, OpenClaw treats it like an ACPX harness session and expects ACP metadata. The VSCode openclaw acp bridge created that key, but it is not an ACPX-spawned session, so the metadata is missing. Then approval follow-up can’t resume the run.

Workaround: force VSCode to use a plain bridge session key that does not contain :acp:.

Use this:

"OpenClaw": {
  "command": "openclaw",
  "args": [

[real copper]

    "acp",
    "--url", "ws://127.0.0.1:18789",
    "--session", "agent:standard:vscode",
    "--reset-session"
  ]
}

Important details:

• remove --require-existing for this new key
• fully restart the VSCode ACP extension/window so it stops reusing the old agent:standard:acp:<uuid>
• do not run /acp doctor inside this VSCode bridge session; test a normal prompt and an approval flow
• if you keep command: "npx", make sure the args are valid JSON and the URL string is closed; but I’d prefer command: "openclaw" if it is already on PATH

After it connects, the logs should mention agent:standard:vscode, not agent:standard:acp:<uuid>. If approvals still fail on that plain key, that’s a different bug and worth filing with the log excerpt here: https://github.com/openclaw/openclaw/issues

[real copper]

Docs for the bridge session mapping: https://docs.openclaw.ai/cli/acp#session-mapping

[hidden roost]

but if i am using the acp client extn(Jan Juan) for vsode to connect to openclaw would it not use acp protocol and send that as part connection to openclaw

[real copper]

Yes, the VSCode ACP client extension is using the ACP protocol to talk to OpenClaw. The confusing bit is that there are two different ACP roles here:

1. VSCode extension → OpenClaw

   • VSCode is the ACP client.
   • openclaw acp is the ACP server/bridge.
   • This creates or targets a normal OpenClaw Gateway session.
   • Good session key example: agent:standard:vscode

2. OpenClaw → ACPX harness

   • OpenClaw is controlling another ACP-capable agent through ACPX.
   • This is what /acp spawn openclaw --bind here does.
   • These sessions use keys like agent:<agentId>:acp:<uuid> and need special ACP metadata.

So yes, VSCode speaks ACP. But it does not automatically mean the Gateway session should be an ACPX harness session.

The bug/edge case you hit is that the bridge’s default isolated key looks like:

[real copper]

agent:standard:acp:<uuid>

That key shape makes other OpenClaw paths think it is an ACPX harness session, so approval follow-up tries to load ACPX metadata and fails.

That’s why I’m suggesting:

agent:standard:vscode

It still uses ACP protocol between VSCode and OpenClaw. It just avoids naming the Gateway session as :acp:, so OpenClaw does not confuse the VSCode bridge session with an ACPX-spawned harness session.

So the mental model is:

openclaw acp --session agent:standard:vscode
= VSCode speaks ACP to OpenClaw bridge

/acp spawn openclaw --bind here
= OpenClaw starts an ACPX harness session

[real copper]

They are related, but not interchangeable.

[hidden roost]

does this looka okay and how can ites approval work with. this sessio 026-05-17T18:14:46.296Z] ConnectionManager: initializing connection to agent agent_1
[2026-05-17T18:14:50.737Z] SessionManager: connecting to agent "OpenClaw"
[2026-05-17T18:14:50.738Z] Spawning agent "OpenClaw" (agent_2): npx openclaw acp --session agent:standard:vscode --reset-session
[2026-05-17T18:14:50.738Z] Using shell: /bin/zsh -l -c 'npx' 'openclaw' 'acp' '--session' 'agent:standard:vscode' '--reset-session'
[2026-05-17T18:14:50.739Z] ConnectionManager: connecting to agent agent_2
[2026-05-17T18:14:50.739Z] ConnectionManager: initializing connection to agent agent_2
[2026-05-17T18:14:51.802Z] ConnectionManager: initialized. Agent: openclaw-acp v2026.5.12
[2026-05-17T18:14:54.870Z] ConnectionManager: initialized. Agent: openclaw-acp v2026.5.12
[2026-05-17T18:14:55.244Z] sessionUpdate: type=session_info_update, sessionId=c031f333-ee0f-49f7-acc1-f967cd5aa827
[2026-05-17T18:14:55.293Z] sessionUpdate: type=available_commands_update, sessionId=c031f333-ee0f-49f7-acc1-f967cd5aa827
[2026-05-17T18:14:55.334Z] Connected to agent OpenClaw, session c031f333-ee0f-49f7-acc1-f967cd5aa827
[2026-05-17T18:15:24.771Z] sendPrompt: session=c031f333-ee0f-49f7-acc1-f967cd5aa827, text="hi..."

[real copper]

Yes, this looks much better.

The good signs:

• it starts openclaw acp --session agent:standard:vscode --reset-session
• it initializes as openclaw-acp v2026.5.12
• it gets session_info_update and available_commands_update
• no ACP metadata is missing in that connection log

The sessionId=c031... is the ACP client protocol session id. The Gateway target should still be agent:standard:vscode underneath.

For approvals with this session:

1. Trigger something that needs exec approval from VSCode.
2. Approve it from one of the approval surfaces:
   • Control UI / Dashboard exec approvals
   • terminal UI, if you are running one

[real copper]

• Telegram native approval buttons, if enabled/configured

3. Watch logs for agent:standard:vscode. You should no longer see agent:standard:acp:<uuid>.

For Telegram approval buttons, your status output showed Telegram is configured and allowFrom=5656179904, so auto mode may already infer you as the approver. If not, set it explicitly:

channels: {
  telegram: {
    execApprovals: {
      enabled: true,
      approvers: ["5656179904"],
      agentFilter: ["standard"],
      target: "dm"
    }
  }
}

[real copper]

Then restart:

openclaw gateway restart

If you still don’t get a button, approve from the Dashboard once to confirm the approval itself works. If Dashboard works but Telegram buttons don’t arrive, the problem is Telegram exec approval delivery/config. If neither works and the log still says agent:standard:vscode, that’s likely a bug worth filing with the VSCode log + gateway log: https://github.com/openclaw/openclaw/issues

Docs:
https://docs.openclaw.ai/cli/acp#session-mapping
https://docs.openclaw.ai/gateway/configuration-reference

[hidden roost]

on the top of chat i am seeing this Sender (untrusted metadata): ```json { "label": "ACP…....can his be problem

[real copper]

No, that “Sender (untrusted metadata)” text is probably not the cause of the ACP approval problem.

That is OpenClaw’s prompt/envelope context. It tells the agent where the message came from, and it is intentionally labeled “untrusted” so the agent does not treat it as instructions. Seeing something like:

Sender (untrusted metadata): { "label": "ACP..." }

usually just means the message came through the ACP bridge/client rather than Telegram/Discord directly.

The thing that mattered for your approval issue was the session key shape. Now that your VSCode bridge is using:

agent:standard:vscode

instead of:

agent:standard:acp:<uuid>

[real copper]

that specific “ACP metadata is missing” path should be avoided.

If approvals still fail, the next useful evidence is the new gateway log line after an approval attempt. Check whether it says agent:standard:vscode or still mentions an old agent:standard:acp:<uuid>.

[hidden roost]

19:29:21
info
gateway/ws
⇄ res ✗ exec.approval.resolve 0ms errorCode=INVALID_REQUEST errorMessage=unknown or expired approval id conn=632be231…06a8 id=2e96f39c…b5cc
19:29:23
info
gateway/ws
⇄ res ✓ exec.approval.waitDecision 2047ms conn=b0387201…ff67 id=f131aff6…ca7c
19:29:23
info
gateway/ws
⇄ res ✓ agent 84ms runId=exec-approval-followup:c3ca50d0-973c-48f0-815a-86030b67a760:nonce:958dae95-3e05-4d1f-8dc3-12d9115e9080 conn=7163074b…f4ba id=99c35718…bc66 ---doe see any issue here ...did the approval work , i did click approve

[real copper]

This looks mostly good.

The first line:

exec.approval.resolve ... unknown or expired approval id

means one approval click tried to resolve an approval that was already gone, expired, or already handled. That can happen if you clicked an old button, double-clicked, or there were two approval prompts and one was stale.

The next two lines are the important ones:

✓ exec.approval.waitDecision 2047ms
✓ agent ... runId=exec-approval-followup:...

That suggests the active approval did get a decision, and OpenClaw successfully dispatched the follow-up back into the agent session. So yes: from these lines, it looks like the approval path worked.

[real copper]

To confirm fully, check the next log/output after this for the actual command result. You want to see either the exec continuing/running, or the VSCode chat receiving the result. If it still fails, the next error should be different now; the old ACP metadata is missing error is not shown here, which is good.

[hidden roost]

exec approval followup dispatch failed (id=c3ca50d0-973c-48f0-815a-86030b67a760): Session followup failed: gateway timeout after 60000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /Users/anujsharma/.openclaw/openclaw.json
Bind: loopback
19:30:23
warn
exec approval followup dispatch failed (id=c3ca50d0-973c-48f0-815a-86030b67a760): Session followup failed: gateway timeout after 60000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /Users/anujsharma/.openclaw/openclaw.json
Bind: loopback.....in vscode logs [2026-05-17T18:29:20.849Z] requestPermission: Command approval requested (autoApprove=ask)
[2026-05-17T18:29:20.854Z] Permission cancelled by user

[real copper]

Now we have the missing piece:

requestPermission: Command approval requested (autoApprove=ask)
Permission cancelled by user

That is coming from the VSCode ACP client side. So OpenClaw/Telegram approval did get far enough to try the follow-up, but the ACP client extension had already cancelled the permission request locally. After that, OpenClaw waited for the resumed session and eventually hit the 60s gateway timeout.

So this is no longer the old ACP metadata is missing problem. It is a permission-handshake mismatch:

• VSCode ACP client asks for command approval
• the client logs Permission cancelled by user
• OpenClaw approval arrives/dispatches later, but the client-side request is already cancelled
• follow-up waits and times out

Things to try:

[real copper]

1. In the VSCode ACP client extension, look for an approval/permission setting and change it from ask to allow/auto-approve if you trust this local OpenClaw session.
2. Keep OpenClaw on agent:standard:vscode; that part is now correct.
3. If the extension has no usable permission UI, approve from VSCode’s own prompt instead of Telegram. Telegram can approve OpenClaw exec approvals, but it may not satisfy the extension’s own ACP permission prompt if the extension cancels it.
4. If you want OpenClaw to be the approval authority, this may need a bug/compat issue between OpenClaw ACP bridge and that VSCode ACP client extension.

Useful issue summary if you file it:
openclaw acp --session agent:standard:vscode connects, exec approval reaches exec.approval.waitDecision, but VSCode ACP client logs requestPermission autoApprove=ask then Permission cancelled by user; OpenClaw follow-up times out after 60000ms.

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

[hidden roost]

[2026-05-17T18:38:27.581Z] <<< AGENT → CLIENT [NOTIFICATION] session/update
{
"jsonrpc": "2.0",
"method": "session/update",
"params": {
"sessionId": "5c8edbdd-ca76-4f4f-a141-a2df5ff04166",
"update": {
"sessionUpdate": "session_info_update",
"title": "Sender (untrusted metadata): ```json { "label": "ACP…",
"updatedAt": "2026-05-17T18:38:26.884Z",
"_meta": {
"sessionKey": "agent:standard:vscode",
"kind": "direct",
"channel": "webchat"
}

[2026-05-17T18:38:27.629Z] <<< AGENT → CLIENT [NOTIFICATION] session/update
{
"jsonrpc": "2.0",
"method": "session/update",
"params": {
"sessionId": "5c8edbdd-ca76-4f4f-a141-a2df5ff04166",
"update": {
"sessionUpdate": "usage_update",
"used": 32995,
"size": 524288,
"_meta": {
"source": "gateway-session-store",
"approximate": true

[2026-05-17T18:38:27.705Z] <<< AGENT → CLIENT [RESPONSE] id=10
{
"jsonrpc": "2.0",
"id": 10,
"result": {
"stopReason": "end_turn"
}
}

[2026-05-17T18:38:28.324Z] >>> CLIENT → AGENT [RESPONSE] id=1
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"outcome": {
"outcome": "selected",
"optionId": "allow-once"

[real copper]

This log is useful. Two things stand out:

1. The session is now correct:

"_meta": { "sessionKey": "agent:standard:vscode" }

So the old agent:standard:acp:<uuid> / missing ACP metadata problem is fixed.

2. The approval response appears after the turn already ended:

18:38:27.705  result: { stopReason: "end_turn" }
18:38:28.324  client response: allow-once

That means the VSCode client did send allow-once, but it may have arrived too late for that particular run. The agent had already ended the turn, so OpenClaw may not have had an active permission wait to resume.

[real copper]

Try one clean fresh test:

1. Restart the VSCode ACP session.
2. Send a prompt that triggers exactly one simple command approval.
3. When the VSCode approval prompt appears, click allow-once there immediately.
4. Check whether the command continues.

If it works from VSCode’s own approval prompt, then Telegram approval is probably racing/too late for this ACP client’s permission flow. If it still ends the turn before allow-once, that points to a compatibility bug in the Jan Juan ACP client extension or OpenClaw’s ACP bridge permission handling.

The title showing Sender (untrusted metadata)... is ugly but not the functional problem. It’s just the session title being derived from the first prompt content.

[hidden roost]

is this ⇄ res ✗ exec.approval.resolve 0ms errorCode=INVALID_REQUEST errorMessage=unknown or expired approval id conn=e5f7e0a1…03df id=77396ea5…4efe
why did it invalidate the request

[real copper]

That line means the gateway received an approval resolution for an approval id it no longer considers pending.

Common reasons:

• you clicked an old approval button after the request already timed out
• you clicked twice; first click consumed it, second click got “unknown or expired”
• VSCode cancelled/ended the permission request before the external approval arrived
• --reset-session or restarting the VSCode ACP session invalidated the pending request
• there were multiple approval prompts and the button/log line belongs to a stale one

The important clue from your earlier log is that VSCode showed:

requestPermission: Command approval requested
Permission cancelled by user

[real copper]

and later the gateway follow-up timed out. So I don’t think OpenClaw randomly invalidated it; more likely the active permission wait disappeared before your approval click was processed.

Best test: start a brand-new VSCode ACP session, trigger one simple command, and approve only the newest prompt immediately. If you see one exec.approval.waitDecision ✓ followed by the command result, it worked. If you see unknown or expired approval id without a successful command result, capture the full sequence from request creation → click → resolve error; that’s issue-worthy.

[hidden roost]

Also i have seen after the approval pile up isee look instacne of telegram in instance telegram in dashnboard , anfd I. see [telegram][diag] spooled update 692746035 handler failed; keeping for retry: GatewayClientRequestError in middleware: unknown or expired approval id
solution: check the folder ./.openclaw/telegram/ingress-spool-default and remove the json file in the folder , check the folder is empty , This get the telegram working.
also i have to run curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/deleteWebhook?drop_pending_updates=true"
...is this the correct approach to deal with problem , or i can do so me configuratioin to not face it

[real copper]

Your cleanup works as an emergency unblock, but I would not treat it as the normal operating procedure.

What is happening:

• Telegram delivered an old approval button callback.
• OpenClaw tried to resolve the approval id.
• Gateway said unknown or expired approval id.
• The Telegram ingress spool kept that update for retry, so it can become a poison-pill update and make Telegram look stuck.

So yes, clearing the stuck spool item can get Telegram moving again. Safer version:

1. Stop/restart the gateway first so it is not processing the same spool file while you edit it.
2. Move the bad JSON file out of the spool folder, don’t permanently delete first.
3. Start the gateway and confirm Telegram works.
4. Only use deleteWebhook?drop_pending_updates=true if you are okay discarding all pending Telegram updates for that bot.

Also double-check the path. On your Mac it is probably under:

[real copper]

~/.openclaw/telegram/ingress-spool-default

not necessarily ./.openclaw/..., unless your current directory happens to be the OpenClaw state dir.

Configuration to reduce this:

• keep only one Telegram bot/gateway instance running for the same bot token
• avoid clicking old approval buttons after the run timed out
• keep VSCode on agent:standard:vscode
• prefer approving the active VSCode prompt for this ACP-client flow, since Telegram approvals seem to race with the client-side permission request
• set Telegram exec approvals explicitly so routing is deterministic:

channels: {

[real copper]

  telegram: {
    execApprovals: {
      enabled: true,
      approvers: ["5656179904"],
      agentFilter: ["standard"],
      sessionFilter: ["agent:standard:vscode"],
      target: "dm"
    }
  }
}

But if a stale/expired approval callback can poison the Telegram spool indefinitely, that sounds like a bug or at least a rough edge. OpenClaw should probably acknowledge/drop expired approval callbacks instead of retrying them forever. Worth filing with this exact log and your workaround: https://github.com/openclaw/openclaw/issues

Docs:
https://docs.openclaw.ai/gateway/configuration-reference

[real copper]

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

[hidden roost]

what does sessionFilter: ["agent:standard:vscode"], would it mean only thes sessoin will be approved for exec filter

[real copper]

Yes, that’s the idea.

sessionFilter: ["agent:standard:vscode"] means Telegram native exec approval prompts should only be sent/handled for approval requests whose session key matches that filter.

So with:

execApprovals: {
  enabled: true,
  approvers: ["5656179904"],
  agentFilter: ["standard"],
  sessionFilter: ["agent:standard:vscode"],
  target: "dm"
}

you are saying:

[real copper]

• only Telegram user 5656179904 can approve
• only requests from OpenClaw agent standard
• only requests for the agent:standard:vscode session
• send the approval prompt by DM

Small nuance: docs say sessionFilter entries are substring or regex-style filters, not a permissions grant by themselves. The actual permission is still the approval decision from an authorized approver. The filter just scopes which approval prompts Telegram will route for that channel.

[hidden roost]

so what happen another session sends exec apporval wwould it fail or would have to manually add that to the session fileter every time

[real copper]

If another session requests exec approval and it does not match sessionFilter, Telegram native approval delivery should skip it. The exec itself does not become automatically approved; it will still wait for approval through another available surface, like Dashboard/Control UI, terminal UI, or whatever approval delivery is configured for that session.

So yes: if you use an exact session filter, you would need to add other session keys when you want Telegram approvals for them.

You have a few options:

• Most restrictive:
  sessionFilter: ["agent:standard:vscode"]
  Only that one VSCode session gets Telegram approval prompts.

• Broader for all standard-agent sessions:
  sessionFilter: ["agent:standard:"]
  Anything under the standard agent can get Telegram approval prompts.

• No session filter:
  omit sessionFilter
  Telegram approvals can route for all sessions that pass agentFilter and approver checks.

[real copper]

Given your stale approval/spool issue, I’d start restrictive while testing. Once stable, either broaden to ["agent:standard:"] or remove sessionFilter and rely on:

approvers: ["5656179904"],
agentFilter: ["standard"],
target: "dm"

That keeps approval power limited to you and the standard agent without requiring a new session key every time.

[hidden roost]

Also I have this issue that i give command on vscode to execute then i have switch to telegram to approve the reqest , is there aw way that i can approve on telegram or vscode and the approval would word ?

[real copper]

In principle, yes: an exec approval can be approved from any approval surface that is wired to the same pending OpenClaw approval id.

For your current VSCode ACP setup, there are two approval layers that can get confused:

1. VSCode ACP client permission prompt

   • This is the ACP client extension asking “allow this command?”
   • Approving here should be fastest because it is local to the request.

2. OpenClaw exec approval

   • This can be approved from Dashboard/Control UI, Telegram native buttons, terminal UI, etc.
   • This is the OpenClaw-side approval system.

The problem you saw is that the VSCode client logged Permission cancelled by user / ended the turn before the Telegram approval follow-up completed. So Telegram approval may arrive too late for that extension’s local permission flow.

Practical recommendation:

• If you are sitting in VSCode, approve in VSCode.

[real copper]

• If you want to approve from Telegram reliably, configure the VSCode/OpenClaw path so the VSCode client does not immediately cancel its own permission request. Look for an extension setting around auto-approve/permissions and avoid ask if you trust this local setup.
• Keep Telegram exec approvals configured as a fallback/remote approval path, but avoid clicking old Telegram approval buttons after the VSCode prompt has already been cancelled.

There may not currently be a perfect “approve from either VSCode or Telegram interchangeably” flow with that ACP client extension, because the extension owns its ACP permission prompt timing. If VSCode keeps cancelling before Telegram can answer, that’s likely a compatibility bug/limitation worth filing.