isolation.cloudDOCS

The activity log

Every action from every door is logged: who, what, which session, when, the outcome, and the source as a kind and a channel. Read it with activity_list.

"Who stopped my session?" is the question the activity log exists to answer. Every action anyone in the organization takes, from every door, is written to one log as it runs: who did it, what they did, which session or server it was about, when, how it ended, and where it came from. That last part is always two things, a kind and a channel, because "a command" does not tell Slack from Teams and "MCP" does not tell Claude Desktop from a script.

What one entry holds

Everything a person or an agent does with Isolation is an action, written once and reachable from five doors. The log is written by the same code that runs the action, so there is no door that skips it.

FieldWhat it says
memberThe member the action ran as. An agent's entry names the member who launched its session, plus the agent.
actionsession_launch, session_stop, member_invite, view_link, and so on.
sessionThe session the action named, or the one it produced (a launch). The server is reached through the session, since a session's server can change on resume.
sourcekind and channel.
argumentsA redacted copy, at most 2 KB.
outcomeok, ask (the action needed one more argument), error (a refusal the caller could act on), or denied (the door or the token was not allowed to call it at all).
errorThe message the caller was given.
ms, atHow long it took, and when.

The five kinds and what their channel means:

  • web, channel spa: the website.
  • command: a chat app. The channel is slack, teams, linear, jira, github or buzz.
  • mcp: an MCP client such as Claude Code, Cursor or Codex. The channel is the OAuth client, or the label of the access token.
  • cli: the same access token used from a terminal. Told apart from mcp by the door, not by guessing.
  • agent: an agent inside a session, calling one of the few actions it is allowed. The channel is its harness: claude, codex or goose. Its actions are pinned to its own session, so an agent entry always names the session it lives in.

A refused call is logged too. An agent asking for session_stop, or a read-only MCP token asking to launch, leaves a denied row with the reason. That is often the entry that explains a confusing tool result.

Reading it

Owners and Admins read the log on the website, or with the activity_list action from any door but the agent's. Newest first, fifty at a time, with filters by session, server, action, kind, channel, member, outcome and time.

/activity                              the latest fifty
/activity in checkout-1                one session, by id or name
/activity in checkout-1 session_stop   who stopped it
/activity on office-mac                every session that ran on one server
/activity by ana since 7d              one member, last seven days
/activity since 2026-09-08T09:00:00Z   an ISO time works too

/audit is an alias. In a chat you get twenty lines; the full page is in the result for anything that renders a table. Names work wherever an id would: a session by its name, a server by its label, a member by name or email. A name that does not exist is refused rather than answered with an empty list, so "nothing" always means nothing happened.

The same filters are the MCP tool's arguments and the CLI's flags. whoami answers with your own connection's kind and channel, said the way the log says it, which is the quickest way to see which door a client of yours is actually on.

What it is for

Audit. Every invitation, role change, removal, server added or removed, preview link shared, and top-up is a row with a member and a source. The rules on organizations, roles and invites are the same at every door, and the log is where you check that they held.

"Who stopped my session?" Filter by the session and session_stop. The row names the Admin, the door, and the minute. If it was an agent, the row names the agent and the member whose session it is. If nobody stopped it, there is no row, and the answer is on the server side: server_logs on that machine.

Cost attribution. The metrics per member and team say what a workspace cost. The log says who launched each session, on which server, from which app, and when, so a figure on the Team page can always be traced back to the act that produced it.

Debugging a connection. A tool call that "did nothing" is usually a denied or error row with the exact sentence the client was given. Filter by kind mcp and the client's channel to see what an external agent tried, and compare with what an external agent can do.

The log is written off the critical path and never fails a call: an audit that could break a launch would be worse than no audit. Entries are kept for 90 days.

Questions

Who can read the activity log?

Owners and Admins. It names what every member launched, stopped and shared, so it belongs to the people who can already list and stop every session. An agent inside a session can never read it.

Does the log keep the arguments of an action?

A redacted copy. Anything named like a secret, token, password, credential or key is dropped, every string is cut to 200 characters, and the whole entry is capped at 2 KB. It records that somebody asked, not what they said.

How long are entries kept?

Ninety days. Older rows are removed by a periodic sweep.