fix(slack): allow channel-id reads for name-allowlisted channels#95313
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 4, 2026, 12:00 PM ET / 16:00 UTC. Summary PR surface: Source +49, Tests +973, Docs +108, Config +93, Other +499. Total +1722 across 20 files. Reproducibility: yes. Current main source denies a Slack channel-ID read when the allowlist is keyed only by channel name, and the contributor supplied redacted live Slack proof showing the failure and the after-fix allowed/denied outcomes. Review metrics: 2 noteworthy metrics.
Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land the Slack runtime fix after maintainer acceptance of the same-token conversations.info fallback for opted-in name matching and exact-head checks finish green. Do we have a high-confidence way to reproduce the issue? Yes. Current main source denies a Slack channel-ID read when the allowlist is keyed only by channel name, and the contributor supplied redacted live Slack proof showing the failure and the after-fix allowed/denied outcomes. Is this the best way to solve the issue? Yes. The Slack action runtime is the narrow owner because it can authorize immediately before protected Slack read API calls using the same read credential; the previous context-name shortcut was removed so generic Channel:"slack" cannot authorize a room. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against e643828af6fa. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +49, Tests +973, Docs +108, Config +93, Other +499. Total +1722 across 20 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
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
Review history (3 earlier review cycles) |
3a40afc to
641838c
Compare
641838c to
ee83402
Compare
|
@clawsweeper re-review. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
Redacted local runtime behavior proofI installed and ran this branch from source on a local OpenClaw gateway, then exercised the Slack Build under test: Relevant redacted config shape: {
channels: {
slack: {
groupPolicy: "allowlist",
dangerouslyAllowNameMatching: true,
channels: {
"#allowed-channel": { enabled: true }
}
}
}
}Allowed-channel read by Slack channel ID: This verifies the patched runtime can accept a Slack read where the action target is a Slack channel ID, while the allowlist entry is a channel name resolved at runtime. Denied-channel read by Slack channel ID: This verifies non-matching channel-ID reads still fail closed. Additional regression coverage on the same head: |
ee83402 to
7e1596f
Compare
|
Follow-up on the three failing checks from run
I rebased this PR onto current
Local verification on the rebased head:
The PR check rollup is now clean on the new head. |
|
Addressed the current Change in
Verification:
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
e3cd608 to
9dbff45
Compare
|
Maintainer pass complete on final head What changed during review:
Proof:
Review artifacts validate READY with zero findings. Ready to land. |
|
Merged via squash.
|
…nclaw#95313) * fix(slack): allow channel-id reads for name-allowlisted channels * fix(slack): trust API lookup for read target names * fix(slack): resolve name-allowlisted reads safely Co-authored-by: Jonathan Tsai <[email protected]> * fix(slack): resolve name-allowlisted reads safely * fix(slack): resolve name-allowlisted reads safely --------- Co-authored-by: Peter Steinberger <[email protected]>


What Problem This Solves
Slack read actions receive channel IDs, while operators may intentionally configure channel access by human-readable name with
dangerouslyAllowNameMatching: true. Before this fix, read messages, file downloads, pin lists, and reaction lists rejected those otherwise-allowed targets before Slack's trusted channel name could be considered.Why This Change Was Made
When direct ID/wildcard policy cannot authorize a read and name matching is explicitly enabled, the Slack action runtime now resolves the target through
conversations.infoand re-evaluates the same channel policy with the returned name.The final implementation keeps the authorization boundary narrow:
Channel: "slack"is never trusted as a room name.User Impact
Operators who opted into Slack channel-name matching can again use read-like actions against allowed channels addressed by ID. Disallowed channels remain blocked, including explicit ID denials and non-matching targets. Config shape, default policy, write actions, and users who do not enable name matching are unchanged.
Evidence
conversations.inforeturns the conversation name according to the presented token's scopes and access; both bot and user tokens are supported.patch is correct, confidence 0.96).tbx_01kwpvwqzx81eqn3ck8kny9yqj, Actions run 28710832081, exit 0: focused tests, full production build, extension and extension-test type checks, lint, database/media guards, and runtime cycle checks.git diff --checkpassed.Live-proof scope: the contributor's real Slack run exercised the same
conversations.infoauthorization behavior before maintainer hardening. The final head additionally changes credential alignment and cache behavior; those refinements have exact mocked-network, type, build, and Testbox coverage but were not repeated against a live workspace.