[BUG] Claude Tag: !help, !routines, !restart silently ignored — commands fall through to the session as ordinary prompts

Summary

In our Team workspace with Claude Tag enabled, none of the documented ! commands are handled by the platform. They are delivered to the session as ordinary prompts, so Claude either answers conversationally or does not respond at all, instead of the fixed action running.

Environment

• Claude Tag (public beta) in Slack, Team plan
• Public channel, Claude invited via /invite, Claude Tag enabled and responding normally to regular @Claude mentions throughout
• Observed 2026-08-20

Reproduction

In a channel where @Claude is responding normally, post each of the following as a human workspace member, as a mention plus the bare command with no extra words:

1. @Claude !help
2. @Claude !routines
3. @Claude !restart — at the channel's top level, not inside a thread

Expected

Per the docs:

• !help replies with the commands understood in the workspace
• !routines replies with the routines set up in the channel
• !restart archives the session and confirms once the replacement is ready, or reports that the restart could not complete

Actual

• !help — no platform response at all.
• !routines — no listing. The session replied conversationally and stated outright that it has no routines listing view, then read the fields out of trigger config by itself as a workaround.
• !restart at channel top level — no response. No confirmation, no failure message, nothing. Tried twice.

Regular mentions in the same channel, in the same minutes, were answered normally within seconds, so the app was live throughout.

Impact

!restart is the documented first-line recovery both for a stuck session and for a thread that has fallen out of step with current org configuration. With commands unhandled there is no recovery path short of abandoning the thread and restating the request. !routines is the only documented way to audit standing work in a channel, so a channel's scheduled jobs cannot be listed or verified by the people relying on them.

The docs note the available command list "can differ by workspace, since a command can be enabled for some workspaces and not others." If that is the mechanism here, the failure mode is still wrong: an unavailable command produces silence rather than an error, and !help — the command whose whole purpose is to report which commands are available — is silent too, so there is no way to discover the situation from inside Slack.

Related gaps observed in the same investigation

Listing briefly in case they are worth separate issues; happy to file individually.

1. No run history for routines. There is no admin-visible record of whether a scheduled routine's run started, succeeded, or failed. Diagnosing a suspected missed run means inferring from what did or did not get posted.
2. Routines have nowhere durable to keep run-to-run state. A recurring digest that reports deltas since its last run needs state, but the sandbox is ephemeral by design, so anything written there is gone by the next run. In our case this made a working routine report "no prior run recorded" on every single run, which we then misread as evidence of missed runs — a self-check that reliably reports failure while the job is in fact succeeding.
3. In-place message edits do not notify, including for escalations. Claude edits its checklist message in place, which is documented and sensible for progress. But when it used that same message to raise a blocking question for humans, Slack sent no notification and nobody saw it. An escalation that needs a human should post fresh rather than edit.