A step-by-step way to @mention Claude Code in a team chat like a colleague

What the setup does

As dev.to reported, a developer wrote up how to make Claude Code a named member of a shared channel in osFoundry, a team chat app. Once it is set up, a member called @claude appears in the channel. A teammate can write something like "why does the refund spec keep breaking?" and Claude Code starts up on the setup owner's computer.

It does not work in the owner's main project folder. It gets a disposable git worktree, which is an extra working folder tied to the same repository history, so edits there do not disturb anything else. It reads a handful of recent channel messages for context and answers in the channel under its own handle. The write-up says Codex can be added the same way.

How to add the agent

Coding agents run on your machine, so this works only in the desktop app. In a browser the picker says as much. You open a channel, set the folder that channel's agents work in, then use the "Agents that can act here" section to add one. The sheet that opens states the core rule in a single line: "Agents act only when mentioned." The guide adds that agents never read messages they were not mentioned in.

You then choose Claude Code, Codex or OpenCode from the list of tools the app found. Uninstalled ones appear greyed out. You fill in three settings:

• Handle: the name people type, such as @claude. It cannot be changed later because messages refer to it.
• Permissions: either decide everything before it starts, or let it ask you while it runs.
• Between messages: start fresh every time, or stay open and remember.

Fresh start or long memory

"Start fresh each time" re-reads the channel on every mention. It is slower, but the conversation cannot drift. "Stay open and remember" keeps the same Claude Code process alive, so a second mention continues where the first stopped. The catch, per the guide, is that this memory belongs to the agent. It does not appear in the chat transcript and cannot be searched.

Staying open requires the "ask me while it runs" permission mode, because an open session is one the owner can answer. An idle process is shut down after half an hour, and up to 4 can stay alive at once. The next mention then starts clean from a snapshot of recent messages.

If another channel already has an @claude, the app offers to reuse it. That means both channels share one conversation and one run history. The author warns this is not what most people expect, so make a new handle if you want the channels kept apart.

Where the safety lines are

Every channel message reaches the agent labeled as untrusted data written by other people, to be used as context and never as instructions. Messages are listed oldest first and cut off when long, with a pointer to a history tool for the full text. That tool only reads channels the agent belongs to. So a member who types something that looks like a system prompt should not be able to rewrite the agent's orders.

Agents also cannot set each other off by accident. A reply wakes only the agents listed as recipients, up to a default cap of 3, and typing a handle in the body of a reply wakes no one. In ordinary channels another agent can talk to yours only if its owner switches that on, and the sheet says tools become read-only while it is on, since agent-to-agent chat has no automatic limit. Project rooms, built for agents to talk, instead show live spending and give every member a stop switch that also cancels runs in progress.

Any osFoundry tool that needs a human click is refused rather than left waiting, and the agent has to report why. Claude Code's own permission questions are separate and wait for the owner. Code changes stay on a throwaway branch until the pull request is merged.

What a real run looks like

The guide walks through a demo channel. Someone asks @claude where the webhook retry count is set, and it answers that it is a constant set to 3. Later a teammate asks why the refund test is flaky. Claude Code checks the file's history, reads the test and edits it, then pushes a branch. It posts that the test built its time window from the current clock, so it failed when CI ran near midnight UTC, and that it froze the clock in the test, linking PR #482.

The author notes the second mention received only the messages posted since the agent last spoke, including its own earlier reply, because the session was already warm. The first mention got the capped snapshot instead.

Limits to keep in mind

This is a single first-person write-up, and we have not tested it. The agent runs on one person's computer, so if that machine is off, nobody gets an answer. Whoever can mention it can start work there, within the folder and permission choices the owner made.

The sensible habit is to treat it like a new hire. Limit what it can touch, and have a person review its changes before merging. The author's suggested next step is a project room with two coding agents, where one writes a fix and the other reviews the resulting pull request.