Pair Programming

Omnigent is multi-user. Once your server is reachable by your team (see Shared Server), you can share a live session with a link, let a teammate co-drive your Omnigent, or fork a conversation so someone can continue independently. The same session works across terminal, web UI, and mobile simultaneously.

Co-drive

A teammate attaches to your running session and their messages execute on your machine. Great for pairing or handing the keyboard to a domain expert mid-investigation.

• In the web UI, hit Share and send the link to your teammate.

  • Share grants one of two permission levels: Read (read-only, teammates watch the session stream) or Edit (teammates can co-drive and send messages). Changing the session's agent — its MCP servers or the agent bundle itself — stays with the owner; see

    Only the owner can change the agent

    .

• From the terminal, run:

  omni attach <session_id>

Teammates see everything in real time: messages, tool calls, and file changes stream to every connected viewer.

Read-only sharing keeps workspace files private

A Read (view-only) share gives a teammate the conversation — messages, tool calls, and streaming updates — but not the session's workspace files. By default, view-only viewers don't see the Files, Changes, or GitHub diff surfaces, because a workspace routinely holds secrets like .env files and keys. Edit collaborators always have workspace access.

To let view-only viewers browse the files too, open the Share dialog and turn on Workspace files ("Let people with view access browse this session's files"). This toggle appears only for sessions that have a workspace on disk, and only the session owner can change it. It's off by default. Turning it off again returns view-only viewers to conversation-only access.

The opt-in never widens absolute-path browsing on the host filesystem — that stays owner-only regardless of this setting.

Co-driving grants code execution on the host

Only share Edit with people you trust to run arbitrary code on your machine. A session runs commands in a non-sandboxed process on whatever machine hosts it, so a teammate with Edit can drive the agent and gets the same access to your filesystem, credentials, and network.

To collaborate more safely, share read-only instead, or host the session on a cloud sandbox host so the agent runs in an isolated remote container rather than on your personal machine. To constrain what the agent can touch even on a trusted host, apply an OS sandbox policy.

What each permission level can do

Everything an Edit collaborator does goes through the agent — messages, workspace-relative file edits, and answering the session's pending prompts — so it passes the same policy and approval gates as the owner's own turns. A few actions bypass the agent entirely and stay with the session owner:

* Off by default; the owner can enable it with the Workspace files toggle described above.

† The caller must own both sessions and the host the terminal runs on.

The permission or approval mode of a native coding-agent session (for example Claude Code's permission mode or Codex's approval preset), and its terminal pass-through launch args, control what runs on the host without asking. Only the session owner can change them. The server enforces this on PATCH /v1/sessions/{session_id} (permission_mode, approval_mode, and terminal_launch_args). In the web UI, Edit collaborators see the composer's permissions dropdown disabled, with the hint "Only the session owner can change the permission mode".

"Pending prompts" covers everything the agent pauses on: policy approval gates, harness permission prompts, questions the agent asks you, plan review, and MCP forms.

The environment shell (POST /v1/sessions/{session_id}/resources/environments/{environment_id}/shell) is owner-only (a server admin may also use it). A command has no path to inspect, so there is no "inside the workspace" form that could safely be opened to collaborators — any command reaches the owner's machine directly and passes no policy or approval gate on the way. It carries the same bar as browsing an absolute path. Collaborators with Edit get a 403 from this endpoint; they can still ask the agent to run commands, which are subject to the session's policies.

Pending prompts are answerable by anyone who can drive the agent (Edit), whether from the web UI's approval bar or the REST elicitation endpoints. A Read share can neither see nor answer them.

Only the owner can change the agent

Co-driving lets a teammate send messages, but it does not let them reconfigure the agent a session runs. Adding, editing, or removing the session's MCP servers, and replacing the session's agent bundle (PUT /v1/sessions/{session_id}/agent), require owner access to the session — Edit is not enough. On top of session ownership, the caller must also own the agent bound to the session (or be a workspace admin). Both checks are enforced by the server, so this applies to API clients as well as the UI.

In the web UI, open the session's actions menu and choose Agent info to see the bound agent's tools and policies. Everyone with access to the session sees the MCP server names listed there; only the owner sees the Manage MCP servers control and the per-server edit and delete actions. Child sessions inherit their parent's access, so an owner keeps the controls in sub-agent sessions too, while a collaborator with Edit sees a read-only list.

Built-in template agents and native coding-agent harnesses (*-native) never expose MCP editing here, regardless of who is looking.

When auth is disabled or the server runs in local single-user mode there is no ownership model, and the MCP controls are always available for editable agents.

Who said what

When more than one authenticated person participates in a session, Omnigent labels each model-visible user message with the author's account, prefixed as [account]: (for example [alice@example.com]: ...), so the agent can tell collaborators apart mid-conversation. Labels appear only once two or more distinct authors have contributed; a solo session is left unlabeled.

The label is informational only. It does not change stored message authors, UI avatars, session ownership, or who may approve or run privileged actions — authorization is unaffected.

To hide the labels from the model, set the environment variable before starting the server:

OMNIGENT_SHARED_MESSAGE_ATTRIBUTION_ENABLED=0 omni server start

The switch is on by default; any of 0, false, no, or off disables it. Disabling it removes the prompt labels only — internal authorship metadata is still stripped from what the model sees, and persisted authors are unchanged.

Fork

Clone a conversation and continue independently from the fork point. The original session is unaffected.

In the web UI, click Clone Session.

From the terminal:

omni run --fork <session_id>

Forking copies the full conversation history up to the fork point. From there, each session diverges independently.

Fork onto a cloud sandbox

By default a fork is created unbound: it starts idle with no runner, and you attach compute afterwards the same way you would when resuming a session. If your server is configured with a cloud sandbox provider, you can instead have the fork land directly on a fresh server-provisioned sandbox host.

In the web UI Clone Session dialog, pick a New Sandbox target instead of an existing host. The server provisions the sandbox, starts the runner, and connects it back automatically — the same background launch a new sandbox session uses, so the clone appears before the sandbox has finished coming up. The sandbox is registered to you, the forking user, so it resolves your credentials rather than the source session owner's.

The sandbox's working directory follows the source by default: leaving the workspace unset inherits the git repository the source session recorded, so cloning a sandbox session lands the fork in the same checkout. You can point the fork at a different repository (https://github.com/org/repo#branch), or choose an empty sandbox instead.

See the fork endpoint in the REST API reference for the host_type, sandbox_provider, and workspace request fields.