Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Default `message` tool `accountId` to the calling agent's own Slack account when omitted [1 pull requests, 2 comments, 3 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#73619•Fetched 2026-04-29 06:17:22
View on GitHub
Comments
2
Participants
3
Timeline
3
Reactions
0
Author
jgoodfellow-truecontextjgoodfellow-truecontext
Participants
brokemac79brokemac79clawsweeper[bot]clawsweeper[bot]jgoodfellow-truecontextjgoodfellow-truecontext
Timeline (top)
commented ×2cross-referenced ×1

PR fix notes

PR #74052: [AI-assisted] fix(outbound): prefer agent account binding for message tool

Description (problem / solution / changelog)

Summary

  • Preserves explicit message tool accountId overrides.
  • Stops the tool wrapper from writing the inherited/default account into params.accountId when the caller omitted it.
  • Resolves omitted-account message actions as explicit accountId first, calling-agent channel binding second, inherited/default account last.
  • Adds regression coverage for the combined inherited/default-account plus calling-agent-binding case.

Closes #73619.

Testing

  • node scripts/test-projects.mjs src/infra/outbound/message-action-runner.plugin-dispatch.test.ts
  • git diff --check
  • corepack pnpm tsgo:core
  • corepack pnpm tsgo:core:test

AI Assistance

AI-assisted with Codex. I understand the change: it keeps user-specified account IDs authoritative while letting an omitted accountId resolve to the calling agent's configured channel binding before falling back to inherited/default context.

Changed files

  • src/agents/tools/message-tool.ts (modified, +4/-4)
  • src/infra/outbound/message-action-runner.plugin-dispatch.test.ts (modified, +29/-1)
  • src/infra/outbound/message-action-runner.ts (modified, +2/-1)
RAW_BUFFERClick to expand / collapse

Problem

When an agent calls the message tool (e.g. action: send on Slack) without an explicit accountId, the call resolves against whatever deliveryContext.accountId the runtime inherited. For subagents this is the parent's account, and for freshly authored routines it tends to be whichever account the author tested under. In practice this has produced a recurring class of bugs in our deployment:

  • Subagent replies posting under the parent agent's Slack identity (wrong handle, wrong avatar, wrong "signed by" line).
  • Cron-authored routines silently posting to the wrong workspace/account.
  • Four distinct Slack attribution incidents across three agents in a single week, all root-caused to a missing or mis-inherited accountId.

We've been band-aiding it by pasting canonical message JSON blocks (with explicit accountId) into every routine and skill, and reviewing new crons for it. That's fragile — the default is the footgun.

Proposal

When accountId is omitted on a message call, default to the calling agent's own configured account for that channel (i.e. the account under channels.slack.accounts.<agentId> or equivalent), not the inherited deliveryContext.accountId. Keep the explicit override working as today.

Alternatives considered

  • Emitting a warning when accountId is omitted — helps discoverability but doesn't fix the attribution-leak class of bug.
  • Requiring accountId — breaking change; also overkill for single-account deployments.

Impact

Single-account deployments: no behavioural change. Multi-agent deployments: subagent and cron posts land under the right identity by default. Existing explicit accountId usage unaffected.

extent analysis

TL;DR

Change the default behavior of the message tool to use the calling agent's own configured account when accountId is omitted.

Guidance

  • Review the channels.slack.accounts configuration to ensure each agent's account is correctly set.
  • Update the message tool to default to the calling agent's account when accountId is not provided, instead of using the inherited deliveryContext.accountId.
  • Test the updated behavior in multi-agent deployments to verify that subagent and cron posts are attributed to the correct account.
  • Consider adding a warning or log message when accountId is omitted to aid in discoverability of potential issues.

Example

No code snippet is provided as the issue does not include specific code details.

Notes

This solution assumes that the channels.slack.accounts configuration is correctly set up for each agent. If this configuration is not in place, additional setup may be required.

Recommendation

Apply the proposed workaround by updating the message tool to default to the calling agent's account when accountId is omitted, as this addresses the root cause of the attribution-leak class of bugs without introducing breaking changes.

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…
#autograd error#model save/load#optimization#mixed precision#training loop

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Default `message` tool `accountId` to the calling agent's own Slack account when omitted [1 pull requests, 2 comments, 3 participants]