IronClaw
IronClaw moves Slack account linking out of the public channel
An IronClaw report says unlinked users receive a public connection message and must complete a manual round trip. The proposed fix sends a private one-click link, while automation work suppresses deterministic no-result messages that otherwise add channel noise.
nearai/ironclaw issue #7681 is the inspected primary source: “Slack: unlinked-user connect message is public and requires a manual round trip.” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- nearai/ironclaw issue #7681 was created 2026-08-16T03:15:48Z and was open at inspection; its title is “Slack: unlinked-user connect message is public and requires a manual round trip.” - nearai/ironclaw PR #7682 was created 2026-08-16T05:10:58Z and was open at inspection; its title is “fix(slack): deliver the unlinked-user connect nudge privately, with a one-click connect link (#7681).” - nearai/ironclaw PR #7651 was created 2026-08-14T10:28:07Z and was open at inspection; its title is “feat(automations): add deterministic no-result suppression.” - The repository reported 12604 stars, 1499 open issues, default branch main, and last push 2026-08-16T20:39:18Z. - The latest tagged-release baseline checked was ironclaw-v1.2.0 published 2026-08-13T23:30:51Z.
What changed
nearai/ironclaw issue #7681 reports: Problem When a Slack user without a linked IronClaw account @-mentions or DMs the bot, the reply is a generic "connect it in the Ironclaw web app, then message me here again" notice. Two issues with this today: 1. **It's not private.** In a shared channel, this reply is visible to everyone in the thread, not just the user who triggered it — reported from a real internal Slack thread where multiple teammates saw the same bot response repeated for each person who tried mentioning it. 2. **It's a manual, multi-step round trip.** The user has to separately: go to the web app, log in (or register), remember to explicitly ask IronClaw in chat to "connect to Slack" (which kicks off OAuth), and only then come back to Slack and try again. Nothing carries context between these steps, so it's easy to get stuck (as seen in the reported thread — the user asked "what's the link to connect you?" because there wasn't one). Proposed solution 1. **Reply ephemerally, not into the shared conversation.** Use Slack's ephemeral-message capability so the connect notice is visible only to the user who triggered it, not the whole channel/thread. 2. **Replace the plain instruction with a single "Connect Slack" link** that does the whole
nearai/ironclaw PR #7682 reports: Summary An unlinked user who @-mentions the bot in a **shared** Slack channel got a connect notice **the whole channel could see**, which also **dead-ended into a manual multi-step process** with no context carried between steps (the reported thread ends with *"what's the link to connect you? guide me pls"*). **Private delivery:** adds a generic OutboundVisibility axis (Public / EphemeralTo(actor)) to OutboundEnvelope, threaded through the notice-class delivery path only. Slack maps EphemeralTo to chat.postEphemeral (same chat:write scope — **no new Slack app permission**). Direct chats keep requesting Public: a DM is already 1:1. **One-click link:** when a channel's connection strategy is OAuth *and* the deployment sets IRONCLAW_REBORN_WEBUI_PUBLIC_URL, the host appends /chat?connect= to the manifest's connect_required copy. /chat is an authenticated route, so the link rides the WebUI's **existing** RequireAuth → redirect_after → login_ticket round-trip **unchanged** — no new auth machinery, no new backend route. The landing hook strips the query param (a reload cannot replay it) and renders a **"Continue to connect Slack" confirmation button** rather than auto-redirecting: the click is a real user gesture, so there is no popup-blocker risk, and the user gets a legible checkpoint instead of being bounced through three redirects. **Ships dark:** deployments that do not set the env var keep today's static, link-free notice.
nearai/ironclaw PR #7651 reports: Summary require trigger_create to provide result_delivery, derived by the model from the user wording; explicit only-notify-on-match/change/result intent selects suppression, while neutral wording deterministically falls back to deliver expose the existing host-owned builtin.structured_result capability only to suppression-enabled scheduled runs, with the narrow { "outcome": "nothing_to_report" } schema replace the free-form [SILENT] sentinel with validated durable evidence; the turn kernel now verifies that the same-run result came from the exact structured-result call before it accepts NothingToReport suppress delivery before reservation/dispatch while preserving ordinary assistant replies, cancellation, failures, legacy persisted defaults, and no-channel behavior Change Type [x] Bug fix [x] New feature [ ] Refactor [x] Documentation [ ] CI/Infrastructure [ ] Security [ ] Dependencies Linked Issue Closes #7647. Validation [x] cargo fmt --all -- --check [x] cargo clippy --all --benches --tests --examples --all-features -- -D warnings — passed in CI for the previous head; focused cargo clippy -p ironclaw_turn_runner --tests -- -D warnings passes for the review fix [ ] cargo build — covered by package tests and CI builds [x] Relevant tests pass: host policy, trigger spec, structured result, agent-loop typed/plain-text/cancellation, turn-runner typed settlement/evidence, and production capability-port tests [ ] cargo test -p --features integration — not applicable; no changed crate exposes a relevant integration feature [x] Manual testing: Railway
Why it matters
Account linking carries identity and authorization context that does not belong in a shared channel. Delivery suppression must also avoid turning expected silence into ambiguous failure. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.
Current
The primary record was open when captured on 2026-08-17. The tagged-release baseline was ironclaw-v1.2.0 published 2026-08-13T23:30:51Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/nearai/ironclaw/issues/7681. Supporting records are https://github.com/nearai/ironclaw/pull/7682 and https://github.com/nearai/ironclaw/pull/7651. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Move connection material into a private scoped surface, bind links to the intended user and workspace, and record why an automation emitted no message without posting noise publicly. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.