# Share agent work with a team without sharing AI accounts

> A host, implementer, and reviewer handoff through Canopy Team: project chat, files, review requests, disk ownership, and separate model accounts.

Canonical HTML: https://canopyide.dev/use-cases/share-agent-work-with-a-team
Article date: 2026-09-28

A team can share the evidence of an agent's work without sharing the agent's login. Start with one project, one host, a named implementer and reviewer, and a decision they need to make. Keep file ownership, provider credentials, and the final PR decision explicit.

## Start with a named host and a specific decision

A Canopy host creates a Team session, and teammates join by code. Share the project that contains the task rather than an undifferentiated collection of terminal screenshots. LAN sessions connect directly; Internet sessions can use an optional tunnel. The current-main README documents end-to-end encrypted Team payloads and the host as the relay. Keep the host running, decide who should join, and check the route and installed release before inviting anyone. The useful request is specific: 'Review the settings retry fix on branch X and tell me whether the failure path is covered.'

## Hand the reviewer evidence, not a transcript

The implementer should give the reviewer the issue or goal, the exact branch or PR, changed files, the local run command, and checks with results. Use Team chat, file exchange, or a review request to point to those artifacts. A copied agent summary is not enough: the reviewer should open the final diff, run or inspect the relevant behavior, and record a finding with evidence. If a preview is available only on the host, identify its URL and which checkout serves it. This lets the reviewer distinguish an implementation error from an old service or wrong branch.

## Keep three kinds of authority separate

Canopy's collaboration documentation says the owner of a shared file remains its only disk writer, even when peers co-edit. The architecture separates Team relay messages from the model CLI and from the local filesystem. A teammate's ability to discuss a project does not grant their agent the host's provider account, and a file collaboration path does not replace a Git branch or PR for integrating a larger change. State the owner of each decision before parallel work begins.

*What a Team session can coordinate and what remains with another owner.*

| Thing | Shared through Canopy Team | Authority to verify |
| --- | --- | --- |
| Task context | Chat, project material, files, and review requests | Task owner confirms current goal and branch |
| Shared file | Collaborative edits or exchange | File owner remains disk writer |
| Code integration | A reviewer can discuss findings | Repository branch, PR permissions, and human reviewer govern merge |
| Model use | Results and bounded handoffs | Each installed CLI's own account, model, limits, and billing |
| Internet access | Optional Team route through a tunnel | Host chooses route and ends access window |

## Run one two-person review loop

For example, an agent on the host fixes a settings form retry. The implementer stops editing at a stable diff, runs the form test, and sends the branch and reproduction steps. The teammate reviews the failure and success paths and replies with a cited concern: the retry button stays disabled after an API error. The implementer assigns a focused fix to the appropriate agent, then sends the new commit and test result. The reviewer checks the latest diff again before the PR owner resolves the thread. That loop is useful even when teammates use different model providers, because the handoff is grounded in the repository and behavior rather than a copied conversation.

## Keep provider accounts and usage separate

Each installed agent CLI uses its own login, model settings, limits, and billing. Canopy can isolate supported CLI profiles and show usage signals that those CLIs expose, but a Team session does not pool paid Claude, Codex, OpenCode, or other provider subscriptions. If another person needs to run an agent, they should use their own authorized CLI account on the host or their own environment, as their team's rules require. Do not exchange passwords or API keys to make a review handoff work. Shared context, files, and PR evidence are the portable part.

## Close the session with an owner and next action

Record what changed, where it changed, what was tested, what remains uncertain, and who owns the next decision. If the review found a bug, keep the finding open until the revised behavior and latest diff are checked. End the Team connection or optional tunnel when its purpose is complete, then check the host's agent and service processes separately. A closed collaboration window does not certify that an agent stopped or a PR was merged. The named PR owner still decides whether the final change is ready.

## Copyable resources

### Two-person agent review handoff

Use artifact links and outcomes, not provider credentials or a full private transcript.

````text
Task and acceptance checks: [ ]
Host/project and component: [ ]
Implementer and reviewer: [ ]
Branch/PR and latest commit: [ ]
Run command and preview checkout/URL: [ ]
Changed files and why: [ ]
Checks run with exact results: [ ]
Reviewer question: [one decision or failure path]
Finding with reproduction and file/line: [ ]
Fix owner and revised commit: [ ]
Final review decision and next owner: [ ]
````

## Frequently asked questions

### Can my teammate use my paid AI model plan through Canopy?

No. Team relay shares project collaboration, not provider credentials or model subscriptions.

### Who writes a shared file to disk?

The file owner remains the only disk writer; teammates collaborate through the relay.

### Does a Team review request let someone merge my PR?

A review request coordinates evidence and feedback. Repository permissions, the final diff and checks, and a human merge decision remain separate.

### Can two agents on different CLI accounts share a conversation?

They can share project facts and a bounded handoff. Their provider conversations and credentials remain with their own CLIs and accounts.

## Sources and further reading

- [Canopy app README: Team collaboration and provider boundaries](https://github.com/FluidWorksApp/canopy-ide/blob/main/README.md)
- [Canopy architecture: Team relay and local authority](https://github.com/FluidWorksApp/canopy-ide/blob/main/docs/architecture.md)
- [GitHub pull request review workflow](https://docs.github.com/en/pull-requests/how-tos/review-pull-requests)

## Related Canopy pages

- [Share agent work with a team without sharing model accounts](https://canopyide.dev/guides/share-ai-agent-context-without-sharing-model-accounts.md)
- [Can Claude Code and Codex agents talk to each other in Canopy?](https://canopyide.dev/use-cases/can-claude-code-and-codex-agents-talk-in-canopy.md)
- [Review an agent-written PR, address comments, and fix CI](https://canopyide.dev/use-cases/review-agent-pr-and-fix-ci.md)
- [Who can control your coding agent through Canopy Remote?](https://canopyide.dev/use-cases/who-can-control-agent-through-canopy-remote.md)
- [Agent session, terminal tab, branch, or worktree: what is the difference?](https://canopyide.dev/guides/agent-session-vs-tab-vs-worktree.md)

Canopy runs installed coding CLIs; CLI accounts, model selection, and provider billing remain separate. Check the installed release before relying on version-specific behavior.