Sessions messaging each other

A session’s agent can reach the other sessions Moontors runs, whatever their agent: a Claude Code session can hand work to a Codex session and hear back. Ask for it in your own words, such as asking your agent to have the Codex session on the API run its tests.

Sessions and the board are in Sessions and the board.

• Moontors gives every session’s agent an MCP server of its own, named moontors, with two tools: list_sessions lists the other open sessions, each with its id, title, agent, model, working folder and status, and send_to_session sends a message into one of them by its id. The agent asks before either as it does before any MCP server’s tool, by its mode, though Codex never asks before list_sessions, which only reads (see Moontors’ own tools), and /mcp lists the server as Moontors’ own (see /mcp).
• The message goes into that session as one typed into its message box would: as its next prompt, or, while it’s working, into its turn or after it, as its agent takes one (see Sending while the agent works). The sending agent is told at once how it went, and never waits for an answer. Its transcript shows the call as a message to that session (see Tools and subagents). If that session’s turn is stopped before its agent takes the message, as with Stop, the message goes first, as that session’s next turn, as one of yours would, and the sending agent isn’t told.
• The receiving agent reads a line of Moontors’ own first, naming the session the message is from and saying that send_to_session answers it. An answer comes back the same way, as a message into the session that sent it.
• In the receiving session’s transcript, the message is a row, as the call that sent it is in the sending session’s: a message from the sending session, by the title it had when it sent it, then the start of the message on a line of its own. Open it for the whole message, with From and that session’s title under it; click that to open the session. It’s still a prompt, with a prompt’s actions on it. One sent into a running turn shows last, “Waits for the agent to take it in”, until its agent takes it in, then where it did. A message waiting for the turn’s end shows that it’s waiting. Where it has joined a waiting message from someone else, each other session’s part is a row of its own, and your own part shows as your messages do, while waiting and once sent, on the phone too.
• A message is always words: one that starts with / runs no command.
• A message to an archived session, to one that doesn’t exist, or to the session itself is refused, and the sending agent is told why.
• Any session may message any other, as often as its agent likes. What a message has an agent do runs under that session’s own permission mode, not the sender’s: a session in Manual can ask one in Bypass to run anything. A back-and-forth that runs on stops as any turn does, with Stop in each session that’s working.
• A session’s tools last as long as its agent runs: once the agent stops, its tools reach no session until it starts again, at the session’s next prompt.
• Some sessions can’t message the others, though they still get messages, as a Gemini CLI session in a folder Gemini CLI doesn’t trust: Known limits names each case.