Live view from your runner | kanman documentation

In a team’s chat you can go one level deeper into any agent: pick it from n active agents above the composer, from the Agents tab, or from the story it works on. The chat then shows that agent’s session: what it thinks, the commands it runs and their output, the files it changes, its pushes and results, live. The composer writes to that agent, and Stop and Take over sit in the session’s header.

For teams that run on kanman Cloud, the session shows the agent’s steps and its log through kanman. For teams that run on your own runners, the full transcript can come directly from your runner to your browser. That is the live view from your runner, and this page is for the people who decide whether to allow it.

In short

Off by default. A team admin switches it on per team in Team > Agent > Live view from your runner. Every change is recorded in the audit log.
Nothing inbound from the internet. The runner and the browser both open only outgoing connections. There is no port forwarding, no public endpoint and no relay.
The stream never passes through kanman. kanman only passes the two sides’ connection offers along and signs who may watch. Code, command output and diffs go straight from the runner to the browser, encrypted.
Only browsers that reach your runner’s network can connect (your VPN or office network). Everyone else sees “Live details are available on your company network” and the condensed timeline.
View-only. The runner accepts nothing on the connection but the viewer’s signed ticket and a close. It never runs or forwards anything a viewer sends.
Every viewer session is a line in the team’s log: who watched which agent, and for how long.

How a viewer connects

A person opens an agent’s session in the app. The browser prepares a WebRTC connection offer (a data channel only, no camera or microphone) without any public server.
The browser sends the offer to kanman. kanman checks that the person is a member of the team, that the team switched the live view on, runs on its own runners and has a turn running right now.
kanman signs a ticket for this one viewer: the person, the team, the agent, the browser’s encryption fingerprint and an expiry of two minutes. The signature uses a key whose public half your runner receives when it registers.
The runner, which already holds an outgoing connection to kanman for its work, picks up the offer. It verifies the ticket’s signature, its expiry, the team and that the fingerprint in the offer is the one in the ticket. If anything is off, it refuses and nothing listens.
The runner answers with its local network addresses only. kanman passes the answer back to the browser.
The browser and the runner connect directly. The connection is encrypted end to end with DTLS; the runner checks that the browser’s certificate has the fingerprint from the ticket, and the browser sends the ticket once more over the connection.
The runner streams that one agent’s events. The app shows Watching directly from your runner while the connection lasts.

What your security team needs to know


Protocol	WebRTC data channel: ICE, DTLS 1.2 or later, SCTP. No audio or video.
Runner ports	UDP 50000 to 50100 on the runner host, for connections from your own network only. Nothing opens to the internet; no inbound rule at your perimeter is needed. If the runner host has its own firewall, allow this UDP range from your VPN and office address ranges.
Addresses offered	The runner’s local interface addresses only (host candidates). With Connect across networks on, the runner and the browser also ask a public STUN server (`stun.l.google.com:19302`) for their outside address; even then there is never a relay (TURN).
What passes through kanman	The two connection offers (session descriptions with the runner’s local addresses and the encryption fingerprints), the signed ticket, and when the session ended with its duration and size. Never the stream.
What the stream carries	One agent’s transcript: its text and thinking, tool calls, commands and their output, file changes, test results. Known tokens of the turn are removed before anything is sent.
Who may watch	Members of the team, one signed ticket per viewer and agent, valid for two minutes to connect. A session ends after two hours at the latest; the browser connects again if needed.
Limits	At most 8 viewers per turn, at most 256 KB/s per viewer.
Audit	Switching the live view on or off is a policy change in the audit log. Every viewer session adds a line to the team’s log: who watched which agent, and for how long.
Encryption keys	kanman’s ticket key is derived from its deployment secret; your runner receives only the public half at registration.

Switch it on or off

Open your team and go to Team > Agent.
Find the card Live view from your runner.
Turn on Live view from your runner. Optionally turn on Connect across networks if people outside your network should be able to try a direct connection.

Only team admins can change these switches. To turn the live view off, switch it off in the same card: kanman stops relaying offers at once, and the runner serves no viewer in any turn after that. Your runner keeps working as before; only the direct stream is gone.

When the runner is not reachable

If your browser is not on the runner’s network, the direct connection does not open. The session then says Live details are available on your company network and keeps showing the condensed timeline: the agent’s steps, launches, results, merge requests and reviews. Messages, Stop and Take over work everywhere, because they go through kanman, not through the stream.