OpenClaw bug report draft

Title

[Bug]: webchat exec approval handoff fails after Allow once; retry generates a new approval ID instead of resuming execution

Summary

In a webchat session, when an exec command requires approval and the user confirms it with Allow once, the approval handoff is unreliable.

In the affected flow, after the user confirms approval and also acknowledges it in chat, the assistant does not cleanly resume the pending command. Instead, when the assistant attempts to continue, OpenClaw generates a new approval ID for the same operation instead of resuming the already approved execution.

In earlier diagnostics of the same bug family, gateway logs also showed:

Error: Channel is required (no configured channels detected)

This appears to be a webchat approval handoff / post-approval routing bug rather than a user approval mistake.

Symptom

Observed behavior:

1. Assistant starts an exec command that requires approval.
2. User clicks Allow once in the approval popup.
3. User confirms in chat that approval was granted.
4. Assistant attempts to continue the same pending operation.
5. Instead of resuming cleanly, OpenClaw issues a new approval request with a new approval ID.
6. The expected completion does not return cleanly to the same webchat session.

Confirmed facts

These points were verified during local diagnostics:

• Approval UI works.
• At least some approval attempts are accepted by the gateway (exec.approval.waitDecision returns success).
• In the affected Niko workflow, completion does not return cleanly to the same session.
• The bug reproduces as a re-exec handoff failure: after approval, retrying the same operation yields a new approval ID instead of resuming the approved one.
• Earlier related diagnostics for the same workflow also showed the recurring gateway error:
  • Channel is required (no configured channels detected)

Evidence

Current exact reproduction symptom

In the latest targeted retest, the assistant reported:

• approval did not complete normally;
• completion did not return to the assistant session;
• after Allow once + user confirmation, retrying the same command produced a new approval ID.

Concrete example from the retest:

• original approval ID: 1dddc1d5
• regenerated approval ID on retry: d8fc33a7

This indicates that the approved operation was not cleanly resumed; instead, the system treated it as requiring a fresh approval cycle.

Earlier related gateway pattern

Earlier diagnostics in the same webchat approval flow repeatedly showed:

• ✓ exec.approval.waitDecision
• immediately followed by
• ✗ agent ... Error: Channel is required (no configured channels detected)

Example observed sequence:

• 2026-03-29T01:40:46.161+02:00 [ws] ⇄ res ✓ exec.approval.waitDecision ...
• 2026-03-29T01:40:46.217+02:00 [ws] ⇄ res ✗ agent ... Error: Channel is required (no configured channels detected)

Execution really happened in related tests

Minimal approved test commands created files successfully in earlier diagnostics, confirming that the issue is not simple approval denial and not generic exec failure.

Examples created during those tests:

• /tmp/openclaw_approval_test_A.txt
• /tmp/openclaw_approval_test_B.txt
• /tmp/openclaw_approval_test_C.txt
• /tmp/openclaw_approval_test_C2.txt
• /tmp/openclaw_approval_test_serpapi_off.txt
• /tmp/openclaw_approval_test_serpapi_off_post.txt

Why this does not look like a config problem

This does not appear to be caused by simple user misconfiguration:

• Approval UI is functioning and approval requests are generated normally.
• Disabling the unrelated serpapi-search plugin did not change the failure signature.
• The bug occurs specifically in the handoff after approval, not in initial approval prompting.
• The same family of symptoms was reproduced multiple times in the same webchat environment.

Likely cause

Likely an OpenClaw bug in webchat approval handoff / post-approval session routing.

Most likely failure mode:

• after approval, the pending exec operation is not re-bound correctly to the original webchat session state;
• when the assistant attempts to continue, the system does not recognize the already-approved operation as resumable;
• instead, it creates a fresh approval cycle and issues a new approval ID;
• in related traces, the same family of failure also appears to fall through into generic outbound channel selection logic, producing:
  • Channel is required (no configured channels detected)

Relevant areas identified during diagnosis:

• resolveMessageChannelSelection(...) / message-channel resolution logic
• webchat route handling in chat.ts, especially the logic around post-send route inheritance / delivery routing after approval
• approval handoff / resume logic that should reconnect a granted approval to the original pending exec

There is also a strong indication that the generic channel-selection path does not correctly fall back to the inbound webchat route for this async completion case.

Related code / diagnostic pointers

From local and public-source inspection, the likely relevant logic areas are:

• message channel selection logic:
  • resolveMessageChannelSelection(...)
• gateway chat route logic:
  • resolveChatSendOriginatingRoute(...)
• observed webchat-specific behavior in chat routing:
  • webchat clients do not inherit external delivery routes in the same way as other flows

This suggests the normal webchat reply path and the post-approval completion path are not using the same delivery binding.

Workaround

Current safe workaround:

After approval, do not assume the assistant can safely continue the pending exec based only on the approval popup result.

Instead:

• have the user confirm approval in chat if needed;
• perform an explicit read-only verification step;
• avoid depending on automatic resume / callback handoff.

Examples:

• read the created file,
• check git status,
• inspect expected output/logs,
• verify side effects directly.

Reproduction outline

1. Start a webchat session.
2. Trigger an exec command that requires approval.
3. Click Allow once in the approval popup.
4. Confirm in chat that approval was granted.
5. Let the assistant attempt to continue the same operation.
6. Observe that:
   • the operation does not cleanly resume;
   • completion does not return normally to the same session;
   • OpenClaw may generate a new approval ID for the same action instead of honoring the approved one;
   • related runs may also emit Channel is required (no configured channels detected).

Environment

• OpenClaw versions observed: 2026.3.24 and 2026.3.28
• Surface: webchat
• Provider: webchat
• Chat type: direct
• OS: macOS

Notes

A related existing issue may be relevant:

• openclaw/openclaw#19979
  • about message-channel resolution lacking context-aware fallback

This report is specifically about the webchat approval handoff / post-approval resume path after exec approval.