Messaging between sessions
If you run Syntic Code in several terminals at once (one session on the API, one on the front end), the sessions can pass notes to each other. You can send one yourself, or let an agent send one. The receiving session’s user always decides what happens to it.
Everything stays on your computer. Messages are small files in your Syntic settings folder (sessions/, readable only by you); nothing goes over the network.
Every session has a handle
Each interactive session announces itself every few seconds with a short handle like session-ab12cd34, a name (the session’s title, or its first prompt) and whether it is working or idle. Sessions that stop announcing themselves drop off the list.
Send a message yourself
Start a prompt with one or more @session-… mentions:
@session-ab12cd34 the API now returns `retryAfter` in seconds; please update the client- Type
@to pick a live session from the list. - Several mentions at the start send the same message to each:
@session-ab12cd34, @session-ff00aa11 rebase on main please. - A mention only counts at the very start.
explain @session handlingis an ordinary prompt. - The message goes to the other sessions, not to this session’s model. This conversation notes that it was sent. A session that refuses messages is reported as refusing, not as delivered.
Let an agent send one
The agent in your main session can see and message your other sessions too:
| Tool | What it does |
|---|---|
ListAgents | Lists the other live sessions on this machine: handle, name, working or idle, and folder (along with the agents of this session). |
SendMessage | Sends a message to a session by handle (session-ab12cd34), id or name. A name matches exactly (ignoring case) or by a unique beginning. |
So you can say “tell the session working on the client that the API field was renamed”, and the agent finds the session and sends the note. Only the main session can do this; a sub-agent that tries is told to report back to its parent instead.
Receiving a message
A message shows up in the receiving session as one folded line:
✉ from api-retry-work: the API now returns `retryAfter` in seconds … +2 lines| Choice | Effect |
|---|---|
| Run | Sends the message to this session’s model as your next prompt. |
| Reply | Starts an answer to the sender. |
| Dismiss | Drops it. |
Any program running as you could write a message file, so a message never starts work on its own unless you say so.
Settings
| Setting | Values | Effect |
|---|---|---|
crossSessionInbound | ask (default), auto, refuse | ask waits for Run, Reply or Dismiss. auto runs incoming messages as your next prompt. refuse drops them and tells the sender. |
sessionMessagesAutoRun | true / false | The same as crossSessionInbound: "auto". |
dialogExpiry | seconds | Dismisses a waiting message if you have not answered in time. |
While permission prompts are bypassed, incoming messages always wait for you, whatever the setting. An organization can fix crossSessionInbound in policy; a policy value other than ask, auto or refuse makes every message be refused until it is fixed.
A message is just text from you or one of your agents. It is shown and handled under the receiving session’s own permission mode and rules; it never grants that session any extra permission.