Coding agents are showing up in team chat.
Codex can take a task from Slack and return a link to the work. GitHub Copilot can open a pull request from a Slack thread. Their chat integrations can begin from something a team was already discussing, before somebody turns it into a careful ticket.
Then somebody replies.
Imagine a coding agent spending an hour inside a repository. It knows why one file was left alone and what the first attempt got wrong. After it posts the result in the team room, a designer asks for a simpler empty state on mobile.
If that reply starts a fresh agent, the useful context stays behind in the terminal. Somebody has to explain the whole thing again... or hope the new session can reconstruct it from the diff.
On August 19, we shipped a return path in hilos: a reply in the room can continue the exact local coding session that posted there.
The return path
The coding tool stays where the person already uses it. Codex, Claude Code, or Cursor runs on their machine, in their checkout, with the permissions they chose there.
When that session posts a message or report to hilos through MCP, a small lifecycle hook records a binding. It holds the provider's session ID and checkout, plus the hilos thread and authenticated agent that made the post. The hook does not read or upload the private coding transcript.
If a teammate replies after the bound message, the local hilos agent picks it up and resumes that provider session in the same checkout. The response returns to the same thread under the same agent's name. If the terminal turn is still running, the reply waits until it stops rather than starting another session beside it.
The binding lasts 48 hours. A reply from last month should not quietly wake an old checkout because somebody found the thread again.
Why the same session matters
Session continuity sounds like plumbing. Mostly it is. It also changes who can steer the work.
The code context stays with the person at the terminal. People in the room can add what the interaction should feel like, or explain why the smaller version is enough for Friday.
A resume flag usually helps one person return to a model later. Here the new message may come from somebody else. The model remembers its work, but the useful event is a teammate noticing something and being able to change the next attempt.
Before this bridge, hilos could receive work from a normal coding session, but the room was basically an export target. A teammate could react to the result. They could not continue it without asking somebody to carry the reply back to the terminal.
The work was visible, but the conversation could not move it.
Engineers already have coding tools they like. We wanted them to keep those tools while the room received the work they produced, with a way back in when somebody had something worth changing.
The awkward implementation bits
MCP is request and response. It can let a running coding agent read a hilos thread or post a report, but it cannot push a future teammate reply into a client that is no longer making requests.
The coding tools already know how to continue their own work. Claude Code has --continue and --resume, for example. Our problem was deciding which future hilos reply was allowed to use that ability, and carrying it to the right local session.
So the return path lives in the existing local hilos agent process. It watches only threads with a recent binding and accepts new replies from people. The bridge ignores replies elsewhere, and an agent post cannot start an agent-to-agent loop.
The session ID was not enough. The bridge also has to prove which agent made the post. Two agents on one machine cannot claim each other's bindings. Private rooms still require membership. A guest in a chat-only room cannot turn a reply into code execution. The credential stays in the local bridge process instead of entering the resumed model's environment.
The real Codex test found less poetic problems too. Project hooks behaved differently between interactive Codex and codex exec. Codex normalized dashes in MCP server names into underscores inside lifecycle events. A documented one-line installer left hooks pointing at a binary that disappeared when npx exited.
Each bug looked small. Any one could make the feature work in a protocol test and fail in the ordinary way somebody uses Codex. We ended up building an acceptance harness around the real Codex CLI. It posts into a seeded hilos room, adds a signed-in person's reply, resumes the exact session in the same checkout, and checks that the answer lands once.
That is a lot of machinery for one ordinary reply. Nobody using it should have to care.
The room gets a say
The coding session does not merge because somebody replied. It can edit and test according to the local tool's permissions, then the work comes back for review. A person still decides what ships.
This is the same reason plan mode belongs in the room. A team has more useful ways to shape a change than approving the final diff. People should be able to question the plan or ask for the smaller version while changing direction is still cheap.
Codex and GitHub Copilot already let people start work from Slack. I care just as much about the way back.
The tiny gesture we were building toward was somebody in the room asking, "Can you try the simpler version?"