Channels
A channel lets an MCP server push a message into a session that is already running. The message arrives as if it were a new prompt, and the agent starts working on it. That turns a session into something other systems can talk to: a chat bridge that forwards messages from your team, a webhook relay that reports a failed deploy, a monitor that says a queue is backing up.
Normally a session only acts when you type. With a channel, the outside world can start a turn, so channels are off for every server until you name it.
This page is a guide. The message format and every field are on the channels reference.
How it works
- You connect an MCP server that supports channels, the same way as any other MCP server.
- When you start a session, you name the servers you trust to push:
syntic --channels <server>. - The server sends a channel message. Syntic Code checks that the server is allowed, wraps the text so the agent knows where it came from, and starts a turn with it.
- The agent works on it with its normal tools and permission checks. Its reply shows in your session as usual.
Pushed messages are marked in the conversation as coming from <channel source="server-name">, so the agent can tell them apart from what you typed and treat them with care.
Set up a channel
Connect a server that supports channels
Add it like any MCP server:
syntic mcp add team-chat -- npx -y @example/chat-bridge-mcpThe server must announce channel support when it connects. A server that does not cannot push, even if you name it.
Name it when you start
syntic --channels team-chatName several with commas (--channels team-chat,deploys) or by repeating the flag.
Send a test message
Trigger the source (post in the chat, fire the webhook). The message appears in your session and the agent starts on it. If you are in the middle of a turn, the message waits in the queue and runs when the turn ends.
Trust a server every time
To avoid typing --channels each time, list trusted servers in your user settings file, ~/.syntic/settings.json:
{ "channels": ["team-chat"] }Project and local settings files cannot add channels. A repository you clone can never open a channel into your session.
Who may push
A message reaches the agent only when all of these hold:
| Check | Set by |
|---|---|
| Channels are on | "channelsEnabled": false in your user settings or managed settings turns them off. |
| The server is trusted | --channels, or channels in your user settings. |
| Your organization allows it | allowedChannelServers in managed settings, when set, must also list it. |
| The server announced channel support | The server, when it connects. |
| No deny rule covers it | A permission deny rule mcp__<server> blocks the server’s messages too. |
A message that fails a check is dropped, and the session shows a short note saying why, for example Ignored a message from 'deploys': it is not listed in --channels.
When permissions are bypassed
While the session runs with permission prompts bypassed, pushed messages are held back and do not start turns. Text from outside must not be able to drive a session that runs every tool without asking.
Limits
| Limit | Value |
|---|---|
| Size of one message | 16 KB. Longer text is cut, with a note giving the full size. |
| Messages waiting per server | 32. Further messages are dropped (and counted) until the queue is read. |
| Extra fields per message | 16 short values (such as a chat id or a sender), passed to the agent as attributes. |
Safety
A channel gives the server a way to start work in your session. Treat it like giving someone a seat at your keyboard:
- Only trust servers you run or know well, and only for sessions where you want them.
- Keep your normal permission rules. The agent still asks before it edits files or runs commands, unless your rules allow them.
- Avoid auto-allowing broad tools in sessions with channels open. A message can ask for anything; your rules decide what actually runs.
- Watch the session. Each pushed message is shown in the transcript before the agent acts on it.
Content arriving through a channel can be written by anyone who can reach the source: a public chat room, an unauthenticated webhook. Make sure the server itself only forwards messages from people you trust.
Channels compared
| Need | Use |
|---|---|
| Something outside Syntic Code starts a turn in your open session | A channel |
| One of your sessions passes a note to another | Messaging between sessions |
| A prompt runs on a timetable while a session is open | Loops and schedules |
| A job starts with no session open | syntic -p from cron or CI (Scripting and CI) |
| A link opens a new session with a prompt ready | Open a session from a link |
Turn channels off
{ "channelsEnabled": false }in ~/.syntic/settings.json turns channels off for you. Administrators can set the same key, and allowedChannelServers, in managed settings.