How do I hand off a coding agent session to a teammate?
To hand off a coding agent session, first decide whether your teammate should continue the same live conversation or start an independent one. Share the task state, relevant code changes, and next step. For live continuation, use a tool with explicit collaborator access and keep its execution environment available.
Last checked against Omnigent v0.19.0 · 2026-10-23
What should a coding-agent handoff include?
Before taking over a coding-agent task, a teammate needs a brief naming the goal, checkout path, branch or base commit, failing or passing checks, unresolved questions, and next action. State whether the agent is still running. If you want the incoming person to wait for that work, say so; otherwise two people may send conflicting instructions into the same investigation.
For example, you have isolated a failing parser test and want its maintainer to continue. Include the exact failing command, what you have ruled out, and any uncommitted patch. Ask the maintainer to reproduce the failure before changing code. A long transcript without the current state leaves them to rediscover which earlier assumptions still hold.
Separate conversation context from repository state. A session link can expose discussion, but it is not a Git clone and does not necessarily include uncommitted files. Transfer a branch or patch when the recipient will use another checkout. Remove secrets from any transcript or artifact you share.
Should I share a coding-agent session or send a Git branch?
Send a Git branch or pull request when your teammate mainly needs the code; share the live coding-agent session when they need to direct the existing agent in its environment. Include a short task brief with the branch so they can review it or begin a new agent conversation. You lose live conversation continuity, but gain a familiar code-review boundary without granting access to your running tools.
A transcript export or conversation fork helps when the reasoning matters as well as the patch. Claude Code documents resume and fork workflows for its own conversations. Those features do not by themselves establish cross-person access to another developer’s running session. Check the tool’s account, history, and machine requirements rather than treating “resume” as a collaboration permission.
Omnigent’s permissioned session sharing fits co-driving: Read access lets a teammate observe, while Edit access lets them send messages and direct the existing agent. Compared with a transcript or Git branch, it preserves the live conversation but grants access to the running environment. Remote terminal sharing is another way to expose a running environment; it requires terminal-access controls rather than conversation-level permissions.
How do I share a coding-agent session in Omnigent?
To hand off a coding-agent session in Omnigent, open Share and grant your trusted teammate Edit access to continue, or Read access to observe. They need access to the same reachable server and, on an authenticated deployment, an account. Prefer a specific collaborator when only one person needs to take over. Sending a URL does not make your local server reachable.
Public Edit requires an administrator to allow it in Settings > Sharing > Maximum public permission; the default maximum remains Read. General access concerns people who can sign in, not anonymous editing. Edit lets a collaborator direct the agent with the session’s available environment and access; it is not merely permission to comment.
Co-driving retains the execution host. If that host is your laptop, the agent’s work still happens there. Keep it awake and connected. Applicable policy, approval, and sandbox gates remain; agreeing who directs the next step is still your responsibility.
For independent continuation, fork rather than co-drive. Omnigent documents omnigent run --fork <session_id> and a web Clone Session workflow. History transfer depends on the harness. Arrange the repository and inputs on the receiving host: a conversation fork does not copy the original working directory or its uncommitted changes.