fix(slack): expose sender bot status in context by masatohoshino · Pull Request #97822 · openclaw/openclaw

masatohoshino · 2026-06-29T14:46:52Z

Prompt request: Make the Slack channel forward sender bot status into the inbound agent context so an operator running allowBots can tell a bot sender from a human, matching what Telegram already exposes, while preserving existing bot detection and filtering.

What Problem This Solves

Slack already detects whether an inbound message was authored by a bot (message.bot_id) and uses that for loop protection, but it never forwards the fact to the agent. With allowBots: true (or "mentions"), a bot-authored message reaches the agent indistinguishable from a human one: the "Sender (untrusted metadata)" block in the prompt has no is_bot field. Operators wiring bot-to-bot or integration flows on Slack therefore cannot have the agent treat bot senders differently, even though Telegram exposes this today.

Why This Change Was Made

The shared inbound context already carries sender bot status end-to-end: buildChannelInboundEventContext maps sender.isBot to SenderIsBot, which renders as is_bot in the untrusted sender metadata block. Telegram populates it; Slack computes the same signal (isBotMessage = Boolean(message.bot_id)) but does not pass it through. This change forwards that existing flag into the sender object Slack already builds, so no core or SDK change is needed. This PR only changes the Slack adapter's inbound context assembly and its tests.

User Impact

Operators with allowBots enabled now see "is_bot": true in the untrusted sender metadata for bot-authored Slack messages, letting their agent or system prompt branch on sender type (for example, not auto-replying to other bots). Human messages are unaffected — the field is simply absent. There is no change when allowBots is off, where bot messages are still filtered as before.

Evidence

Direct production-path run via node --import tsx — real production functions with no mocked I/O, not a vitest or CI run (and not a full live Slack network smoke): the Slack inbound path prepareSlackMessage and the prompt renderer buildInboundUserContextPrefix were invoked directly for an admitted bot-authored room message (allowBots: true, explicit owner present) and a human DM. Redacted terminal output of the agent-visible Sender (untrusted metadata) block:

=== bot-authored room message admitted (allowBots, owner present) ===
ctxPayload.SenderIsBot = true
Sender (untrusted metadata):
{
  "label": "deploy-bot (B0AGV8EQYA3)",
  "id": "B0AGV8EQYA3",
  "name": "deploy-bot",
  "is_bot": true
}

=== human DM ===
ctxPayload.SenderIsBot = undefined
Sender (untrusted metadata):
{
  "label": "Alice (U1)",
  "id": "U1",
  "name": "Alice"
}

The admitted bot message reaches the agent prompt with is_bot: true in the untrusted sender metadata; the human message omits the field. The same bot and human behavior is also asserted by focused unit tests in prepare.test.ts.

clawsweeper · 2026-06-29T14:48:20Z

Codex review: needs maintainer review before merge. Reviewed June 30, 2026, 1:11 PM ET / 17:11 UTC.

Summary
The branch forwards Slack's existing bot-message detection into sender context and adds focused Slack prepare tests for admitted bot and human messages.

Reproducibility: yes. from source inspection. Current main computes Slack isBotMessage and can admit bot messages under allowBots, but the sender facts passed to shared inbound context omit isBot.

Review metrics: 1 noteworthy metric.

Current-main tree diff: 2 Slack files changed, +21/-0. This distinguishes the real merge result from the stale broad PR file listing and dependency-guard comments.

Stored data model
Persistent data-model change detected: migration/backfill/repair: docs/tools/acp-agents.md, migration/backfill/repair: test/e2e/qa-lab/runtime/docker-e2e-lane.fixture.test.ts, migration/backfill/repair: test/e2e/qa-lab/runtime/docker-e2e-lane.fixture.ts, persistent cache schema: extensions/codex/src/app-server/app-inventory-cache.test.ts, serialized state: src/plugin-sdk/persistent-dedupe.ts, unknown-truncated-pull-files. Confirm migration or upgrade compatibility proof before merge.

Merge readiness
Overall: 🦞 diamond lobster
Proof: 🦞 diamond lobster
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Risk before merge

[P1] The visible dependency-guard comments appear stale relative to the current-main tree diff; maintainers may need a rebase or exact-head rerun to clear automation noise before merge.

Maintainer options:

Decide the mitigation before merge
Land the narrow Slack sender-context fix after exact-head checks confirm the merge result remains source/test-only and keeps existing bot filtering unchanged.
Pause or close
Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

[P2] No repair lane is needed; the current-main diff is already the focused source/test change, with remaining action limited to maintainer merge handling and exact-head gates.

Security
Cleared: Cleared: the actual current-main tree diff only touches Slack prepare source/tests and does not change dependencies, workflows, auth, permissions, or secret handling.

Review details

Best possible solution:

Land the narrow Slack sender-context fix after exact-head checks confirm the merge result remains source/test-only and keeps existing bot filtering unchanged.

Do we have a high-confidence way to reproduce the issue?

Yes, from source inspection. Current main computes Slack isBotMessage and can admit bot messages under allowBots, but the sender facts passed to shared inbound context omit isBot.

Is this the best way to solve the issue?

Yes. Passing the already-computed Slack bot fact into existing sender facts is the narrow owner-boundary fix; changing core prompt rendering or adding SDK surface would duplicate existing behavior.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against f284ce3b4df7.

Label changes

Label changes:

add rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
remove rating: 🐚 platinum hermit: Current PR rating is rating: 🦞 diamond lobster, so this older rating label is no longer current.

Label justifications:

P2: This is a bounded Slack bug fix for operators who intentionally admit bot-authored Slack messages and need sender type in agent context.
rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): Sufficient: the PR body includes redacted terminal output from a direct production-path Slack prepare and prompt-rendering run for admitted bot and human cases.
proof: sufficient: Contributor real behavior proof is sufficient. Sufficient: the PR body includes redacted terminal output from a direct production-path Slack prepare and prompt-rendering run for admitted bot and human cases.

Evidence reviewed

What I checked:

Current Slack gap: Current main computes isBotMessage from Slack message.bot_id but the sender object passed to buildChannelInboundEventContext omits isBot, so admitted bot messages cannot render SenderIsBot. (extensions/slack/src/monitor/message-handler/prepare.ts:528, f284ce3b4df7)
Shared context support already exists: The shared inbound context builder already maps params.sender.isBot to SenderIsBot, so the Slack fix can stay inside the Slack adapter boundary. (src/channels/inbound-event/context.ts:506, f284ce3b4df7)
Prompt rendering support already exists: Inbound metadata rendering already emits a boolean SenderIsBot as is_bot in the untrusted sender metadata block. (src/auto-reply/reply/inbound-meta.ts:651, f284ce3b4df7)
Sibling channel parity: Telegram already passes msg.from?.is_bot through sender.isBot, matching the parity claim in the PR body. (extensions/telegram/src/bot-message-context.session.ts:506, f284ce3b4df7)
PR implementation: The PR head adds isBot: isBotMessage || undefined to Slack sender facts at the existing inbound context call site. (extensions/slack/src/monitor/message-handler/prepare.ts:1274, e702c8f2c811)
PR regression tests: The PR head asserts an admitted Slack bot-authored room message sets ctxPayload.SenderIsBot to true and a human message leaves it undefined. (extensions/slack/src/monitor/message-handler/prepare.test.ts:1063, e702c8f2c811)

Likely related people:

steipete: Recent history includes central inbound supplemental context work and repeated Slack prepare maintenance around the sender/context boundary this PR uses. (role: feature-history owner; confidence: medium; commits: 1507a9701b83; files: extensions/slack/src/monitor/message-handler/prepare.ts, src/channels/inbound-event/context.ts)
lin-hongkuan: Implemented the Telegram sender bot-status path that established the sibling-channel parity this Slack fix follows. (role: adjacent invariant contributor; confidence: medium; commits: 69b0604f313d; files: src/channels/inbound-event/context.ts, src/auto-reply/reply/inbound-meta.ts, extensions/telegram/src/bot-message-context.session.ts)
vincentkoc: Recent test/session fixture work touches Slack prepare tests, and the current PR head includes a maintainer-authored refresh commit on the branch. (role: recent area contributor; confidence: medium; commits: 0a3aa5f27860, e702c8f2c811; files: extensions/slack/src/monitor/message-handler/prepare.test.ts)
bek91: Recent merged Slack thread-context work touched the same prepare path shortly before this PR. (role: recent Slack contributor; confidence: low; commits: 9c95abd49d45; files: extensions/slack/src/monitor/message-handler/prepare.ts, extensions/slack/src/monitor/message-handler/prepare.test.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

github-actions · 2026-06-30T17:05:18Z

Dependency Guard

This PR changes dependency-related files. Maintainers should confirm these changes are intentional.

Changed files:

extensions/qa-lab/package.json
pnpm-lock.yaml
pnpm-workspace.yaml

Maintainer follow-up:

Review whether the dependency changes are intentional.
Inspect resolved package deltas when lockfile, shrinkwrap, or workspace dependency policy changes are present.
Treat package-lock.json and npm-shrinkwrap.json diffs as security-review surfaces.
Run pnpm deps:changes:report -- --base-ref origin/main --markdown /tmp/dependency-changes.md --json /tmp/dependency-changes.json locally for detailed release-style evidence.

github-actions · 2026-06-30T17:05:37Z

Dependency graph changes are blocked

OpenClaw does not accept dependency graph changes through PRs unless a repository admin or security explicitly authorizes the current head SHA. Dependency updates are generated internally by maintainers so external PRs cannot change the resolved graph.

Detected dependency graph changes:

pnpm-lock.yaml changed.
extensions/qa-lab/package.json changed devDependencies.

Auto-scrub was not attempted because this PR changes package manifest dependency graph fields:

extensions/qa-lab/package.json changed devDependencies.

Dependency graph changes must be reviewed by security or handled by maintainers internally. Please remove lockfile changes manually if they are not needed.

To remove lockfile changes, restore them from the target branch:

git fetch origin
git checkout 'origin/main' -- 'pnpm-lock.yaml'
git commit -m 'chore: remove dependency lockfile change'
git push

If this PR intentionally needs a dependency graph change, ask a repository admin or member of @openclaw/openclaw-secops to comment:

/allow-dependencies-change

The action will approve the current head SHA (e702c8f2c811962048c699b31f5fa8108727b3fe) when it reruns. A later push requires a fresh approval.

vincentkoc · 2026-06-30T17:29:48Z

Merged via squash.

Prepared head SHA: e702c8f2c811962048c699b31f5fa8108727b3fe
Landed commit: 5c4e478df4ef92237cc26711fe0506021621dacd

* fix(slack): expose sender bot status in context * fix(slack): expose sender bot status in context --------- Co-authored-by: Vincent Koc <[email protected]>

* fix(slack): expose sender bot status in context * fix(slack): expose sender bot status in context --------- Co-authored-by: Vincent Koc <[email protected]> (cherry picked from commit 5c4e478)

fix(slack): expose sender bot status in context

dc74f26

openclaw-barnacle Bot added channel: slack Channel integration: slack size: XS labels Jun 29, 2026

fix(slack): expose sender bot status in context

e702c8f

vincentkoc requested a review from a team as a code owner June 30, 2026 17:04

openclaw-barnacle Bot added docker Docker and sandbox tooling agents Agent runtime and tooling extensions: device-pair extensions: talk-voice channel: qqbot extensions: qa-lab extensions: codex plugin: google-meet plugin: file-transfer extensions: firecrawl extensions: ollama labels Jun 30, 2026

github-actions Bot added the dependencies-changed PR changes dependency-related files label Jun 30, 2026

openclaw-barnacle Bot added size: XL and removed size: XS labels Jun 30, 2026

clawsweeper Bot added rating: 🦞 diamond lobster Very strong PR readiness with only minor maintainer review expected. and removed rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. labels Jun 30, 2026

vincentkoc merged commit 5c4e478 into openclaw:main Jun 30, 2026
339 of 351 checks passed

github-actions Bot mentioned this pull request Jun 30, 2026

📡 Upstream Digest — 2026-06-30 17:46 UTC curtismercier/openclaw-mods#1177

Open

masatohoshino deleted the fix/slack-sender-bot-status branch July 1, 2026 14:44

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(slack): expose sender bot status in context#97822

fix(slack): expose sender bot status in context#97822
vincentkoc merged 2 commits into
openclaw:mainfrom
masatohoshino:fix/slack-sender-bot-status

masatohoshino commented Jun 29, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 29, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jun 30, 2026

Uh oh!

github-actions Bot commented Jun 30, 2026

Uh oh!

Uh oh!

vincentkoc commented Jun 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

masatohoshino commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Uh oh!

clawsweeper Bot commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jun 30, 2026

Dependency Guard

Uh oh!

github-actions Bot commented Jun 30, 2026

Dependency graph changes are blocked

Uh oh!

Uh oh!

vincentkoc commented Jun 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

masatohoshino commented Jun 29, 2026 •

edited

Loading

clawsweeper Bot commented Jun 29, 2026 •

edited

Loading