Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Subagent completion announce uses child agent's accountId instead of parent session's delivery context, causing Feishu "open_id cross app" 400 error [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#74080•Fetched 2026-04-30 06:28:45
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
zdh1207Gitzdh1207Git
Participants
clawsweeper[bot]clawsweeper[bot]zdh1207Gitzdh1207Git
Timeline (top)
cross-referenced ×3labeled ×2closed ×1commented ×1

Description When a parent agent (bound to Feishu app A) spawns a subagent that runs under a different agent (bound to Feishu app B), the subagent completion announce delivery incorrectly uses the child agent's accountId (app B) to send the reply back to the parent session's user. Since the user's open_id belongs to app A, Feishu rejects the message with 99992361 open_id cross app. Reproduction Steps Configure multiple Feishu app accounts in openclaw.json: Set up agent bindings so different agents use different Feishu accounts: From the main agent session (using default account), spawn a subagent targeting qmt-assistant: Subagent completes successfully → announce triggers → delivery fails with 400 Expected Behavior The announce delivery should use the parent session's delivery context (accountId: default), not the child agent's binding accountId. Actual Behavior The announce delivery uses the child agent's accountId (QMT-assistant), causing: Feishu API 400: code 99992361, msg: "open_id cross app" Root Cause Analysis In subagent-announce-delivery-Bem23fvt.js, resolveSubagentCompletionOrigin() calls createBoundDeliveryRouter().resolveDestination() with targetSessionKey: params.childSessionKey (the child session). This finds a binding for the child agent's Feishu account, which then gets used as the accountId for delivery back to the parent session's user.

Key code path: resolveSubagentCompletionOrigin() → resolveDestination({ targetSessionKey: childSessionKey }) // ← should be parentSessionKey → finds child agent's Feishu binding → returns accountId = "QMT-assistant" → delivery uses "assistant" appId + user's open_id (belongs to "default" app) → Feishu 400: open_id cross app

The targetSessionKey should be the parent (requester) session key, not the child session key, when resolving the delivery origin for announce. Environment OpenClaw: 2026.4.24 (cbcfdf6) Node.js: v22.22.2 Channel: Feishu (multiple accounts) OS: Linux (Ubuntu) Impact 17+ failed deliveries accumulated since April 24, 2026 All subagent completion announcements from main → assistant or main → info-officer silently fail Parent agent's reply in the same turn also fails (delivery context polluted) User never receives subagent results unless they manually prompt again Workaround No clean workaround exists. Removing bindings breaks agent identity separation. The only option is to accept message loss and have the user prompt again to trigger a fresh turn with correct delivery context.

Root Cause

Description When a parent agent (bound to Feishu app A) spawns a subagent that runs under a different agent (bound to Feishu app B), the subagent completion announce delivery incorrectly uses the child agent's accountId (app B) to send the reply back to the parent session's user. Since the user's open_id belongs to app A, Feishu rejects the message with 99992361 open_id cross app. Reproduction Steps Configure multiple Feishu app accounts in openclaw.json: Set up agent bindings so different agents use different Feishu accounts: From the main agent session (using default account), spawn a subagent targeting qmt-assistant: Subagent completes successfully → announce triggers → delivery fails with 400 Expected Behavior The announce delivery should use the parent session's delivery context (accountId: default), not the child agent's binding accountId. Actual Behavior The announce delivery uses the child agent's accountId (QMT-assistant), causing: Feishu API 400: code 99992361, msg: "open_id cross app" Root Cause Analysis In subagent-announce-delivery-Bem23fvt.js, resolveSubagentCompletionOrigin() calls createBoundDeliveryRouter().resolveDestination() with targetSessionKey: params.childSessionKey (the child session). This finds a binding for the child agent's Feishu account, which then gets used as the accountId for delivery back to the parent session's user.

Fix Action

Fix / Workaround

The targetSessionKey should be the parent (requester) session key, not the child session key, when resolving the delivery origin for announce. Environment OpenClaw: 2026.4.24 (cbcfdf6) Node.js: v22.22.2 Channel: Feishu (multiple accounts) OS: Linux (Ubuntu) Impact 17+ failed deliveries accumulated since April 24, 2026 All subagent completion announcements from main → assistant or main → info-officer silently fail Parent agent's reply in the same turn also fails (delivery context polluted) User never receives subagent results unless they manually prompt again Workaround No clean workaround exists. Removing bindings breaks agent identity separation. The only option is to accept message loss and have the user prompt again to trigger a fresh turn with correct delivery context.

Impact 17+ failed deliveries accumulated since April 24, 2026 All subagent completion announcements from main → assistant or main → info-officer silently fail Parent agent's reply in the same turn also fails (delivery context polluted) User never receives subagent results unless they manually prompt again Workaround No clean workaround exists. Removing bindings breaks agent identity separation. The only option is to accept message loss and have the user prompt again to trigger a fresh turn with correct delivery context.

PR fix notes

PR #74179: fix(subagent-announce-delivery): prefer parent session binding for completion announce

Description (problem / solution / changelog)

Fix #74080

When a parent agent (bound to Feishu app A) spawns a subagent running under a different agent (bound to Feishu app B), the completion announce delivery was first looking up the child agent's binding, then falling back to the parent.

On multi-Feishu configurations this causes delivery to use the child's accountId (app B) when the parent's accountId (app A) is needed, resulting in a Feishu 400 open_id cross app error.

The fix: try the parent (requester) session binding first, and only fall back to the child session if the parent has no bound delivery context.

Key change in subagent-announce-delivery.ts:

  • route (requester/parent) is now resolved before childRoute\n- Fallback order: parent binding → child binding → hook runner

Changed files

  • src/agents/subagent-announce-delivery.ts (modified, +12/-9)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Description When a parent agent (bound to Feishu app A) spawns a subagent that runs under a different agent (bound to Feishu app B), the subagent completion announce delivery incorrectly uses the child agent's accountId (app B) to send the reply back to the parent session's user. Since the user's open_id belongs to app A, Feishu rejects the message with 99992361 open_id cross app. Reproduction Steps Configure multiple Feishu app accounts in openclaw.json: Set up agent bindings so different agents use different Feishu accounts: From the main agent session (using default account), spawn a subagent targeting qmt-assistant: Subagent completes successfully → announce triggers → delivery fails with 400 Expected Behavior The announce delivery should use the parent session's delivery context (accountId: default), not the child agent's binding accountId. Actual Behavior The announce delivery uses the child agent's accountId (QMT-assistant), causing: Feishu API 400: code 99992361, msg: "open_id cross app" Root Cause Analysis In subagent-announce-delivery-Bem23fvt.js, resolveSubagentCompletionOrigin() calls createBoundDeliveryRouter().resolveDestination() with targetSessionKey: params.childSessionKey (the child session). This finds a binding for the child agent's Feishu account, which then gets used as the accountId for delivery back to the parent session's user.

Key code path: resolveSubagentCompletionOrigin() → resolveDestination({ targetSessionKey: childSessionKey }) // ← should be parentSessionKey → finds child agent's Feishu binding → returns accountId = "QMT-assistant" → delivery uses "assistant" appId + user's open_id (belongs to "default" app) → Feishu 400: open_id cross app

The targetSessionKey should be the parent (requester) session key, not the child session key, when resolving the delivery origin for announce. Environment OpenClaw: 2026.4.24 (cbcfdf6) Node.js: v22.22.2 Channel: Feishu (multiple accounts) OS: Linux (Ubuntu) Impact 17+ failed deliveries accumulated since April 24, 2026 All subagent completion announcements from main → assistant or main → info-officer silently fail Parent agent's reply in the same turn also fails (delivery context polluted) User never receives subagent results unless they manually prompt again Workaround No clean workaround exists. Removing bindings breaks agent identity separation. The only option is to accept message loss and have the user prompt again to trigger a fresh turn with correct delivery context.

Steps to reproduce

Reproduction Steps Configure multiple Feishu app accounts in openclaw.json: Set up agent bindings so different agents use different Feishu accounts: From the main agent session (using default account), spawn a subagent targeting qmt-assistant: Subagent completes successfully → announce triggers → delivery fails with 400 Expected Behavior The announce delivery should use the parent session's delivery context (accountId: default), not the child agent's binding accountId. Actual Behavior The announce delivery uses the child agent's accountId (QMT-assistant), causing: Feishu API 400: code 99992361, msg: "open_id cross app" Root Cause Analysis In subagent-announce-delivery-Bem23fvt.js, resolveSubagentCompletionOrigin() calls createBoundDeliveryRouter().resolveDestination() with targetSessionKey: params.childSessionKey (the child session). This finds a binding for the child agent's Feishu account, which then gets used as the accountId for delivery back to the parent session's user.

Expected behavior

Expected Behavior The announce delivery should use the parent session's delivery context (accountId: default), not the child agent's binding accountId. Actual Behavior The announce delivery uses the child agent's accountId (QMT-assistant), causing: Feishu API 400: code 99992361, msg: "open_id cross app" Root Cause Analysis In subagent-announce-delivery-Bem23fvt.js, resolveSubagentCompletionOrigin() calls createBoundDeliveryRouter().resolveDestination() with targetSessionKey: params.childSessionKey (the child session). This finds a binding for the child agent's Feishu account, which then gets used as the accountId for delivery back to the parent session's user.

Actual behavior

Actual Behavior The announce delivery uses the child agent's accountId (QMT-assistant), causing: Feishu API 400: code 99992361, msg: "open_id cross app" Root Cause Analysis In subagent-announce-delivery-Bem23fvt.js, resolveSubagentCompletionOrigin() calls createBoundDeliveryRouter().resolveDestination() with targetSessionKey: params.childSessionKey (the child session). This finds a binding for the child agent's Feishu account, which then gets used as the accountId for delivery back to the parent session's user.

OpenClaw version

2026.2.24

Operating system

Ubuntu 24.04

Install method

npm global

Model

GLM-5-turbo

Provider / routing chain

Bigmodel

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Impact 17+ failed deliveries accumulated since April 24, 2026 All subagent completion announcements from main → assistant or main → info-officer silently fail Parent agent's reply in the same turn also fails (delivery context polluted) User never receives subagent results unless they manually prompt again Workaround No clean workaround exists. Removing bindings breaks agent identity separation. The only option is to accept message loss and have the user prompt again to trigger a fresh turn with correct delivery context.

Additional information

No response

extent analysis

TL;DR

The most likely fix is to update the resolveSubagentCompletionOrigin() function to use the parent session key instead of the child session key when resolving the delivery origin for announce.

Guidance

  • Identify the resolveSubagentCompletionOrigin() function in subagent-announce-delivery-Bem23fvt.js and update the targetSessionKey parameter to use the parent session key instead of params.childSessionKey.
  • Verify that the createBoundDeliveryRouter().resolveDestination() method is correctly resolving the delivery origin using the updated targetSessionKey.
  • Test the updated code to ensure that the announce delivery is using the parent session's delivery context (accountId: default) instead of the child agent's binding accountId.
  • Monitor the application logs to ensure that the fix has resolved the issue and that no new errors are being introduced.

Example

// Updated resolveSubagentCompletionOrigin() function
function resolveSubagentCompletionOrigin(params) {
  const parentSessionKey = getParentSessionKey(); // assume this function exists
  const deliveryRouter = createBoundDeliveryRouter();
  const destination = deliveryRouter.resolveDestination({ targetSessionKey: parentSessionKey });
  // ...
}

Notes

The provided code snippet is hypothetical and may require modifications to fit the actual implementation. Additionally, this fix assumes that the getParentSessionKey() function exists and correctly returns the parent session key.

Recommendation

Apply the workaround by updating the resolveSubagentCompletionOrigin() function to use the parent session key, as this is the most direct way to resolve the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Expected Behavior The announce delivery should use the parent session's delivery context (accountId: default), not the child agent's binding accountId. Actual Behavior The announce delivery uses the child agent's accountId (QMT-assistant), causing: Feishu API 400: code 99992361, msg: "open_id cross app" Root Cause Analysis In subagent-announce-delivery-Bem23fvt.js, resolveSubagentCompletionOrigin() calls createBoundDeliveryRouter().resolveDestination() with targetSessionKey: params.childSessionKey (the child session). This finds a binding for the child agent's Feishu account, which then gets used as the accountId for delivery back to the parent session's user.

#api#SSR setup#ISR setup#authentication setup#request error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING