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).
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.

An admin can restrict or disable sharing server-wide (read-only, or off entirely), and turn off public "anyone-with-the-link" access. If the Share control is missing or capped at read-only, that's the server's sharing policy — see Session sharing.

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.

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.