Skip to main content

Buyer guide

OpenCode Team Rollout Playbook

Pin a version, restrict model access through central config, set the permission policy, and verify agent work before merge.

Reading time
2 min read
Sources
16 cited
In this piece
OpenCode+27 Positive

The call

Roll OpenCode out through a platform owner who pins the version and ships central config and a permission policy first; engineers who install it on their own get the permissive defaults.

How should a team move OpenCode from a few enthusiasts to everyday use without inheriting its defaults? Pin a version, lock providers and data paths, keep agents inside a policy while they run, and verify their claims before merge.

When you need this

  • Engineers already run OpenCode on personal keys and you want one supported setup.
  • You use models from several vendors and want one agent across them.
  • Security asks where prompts, titles, and keys go before a wider rollout.
  • Package managers have started installing OpenCode 2 over version 1.

Run the rollout

  1. Before work: pin one version

    Which OpenCode will every engineer run?

    What good looks likeOne major version, pinned. OpenCode 1 and 2 share the opencode command, Homebrew's default formula and the Arch package now install version 2, and OpenCode 2 point releases shipped several times a week in October 2026. Test each upgrade on a sample repository before it reaches the team.

  2. Before work: lock providers and data paths

    Can a request leave your approved providers?

    What good looks likeEnterprise central config with SSO, restricted to your internal AI gateway with other providers disabled. Without Enterprise, set model and small_model explicitly, disable share pages, and decide whether Zen, Go, or free models are allowed, since each has its own retention terms.

  3. Before work: keep keys out of the Console

    Where do provider keys live?

    What good looks likeKeys in your gateway or secret manager. OpenCode disclosed a breach of 1.4% of Console accounts on October 17, 2026, so any key saved there needs a spend limit and a rotation plan.

  4. During work: run agents inside a policy

    What may the agent do without asking?

    What good looks likeThe deny-first rules in the companion permission guide, checked into the repository's opencode.json, with containers for any run that uses --auto. Nango confined each headless agent to its own directory after agents read each other's test data.

  5. During work: drive it headless where it pays

    Which work belongs in a pipeline and which belongs in a terminal?

    What good looks likeRepeated, well-specified tasks run through opencode run, the server API, or the SDK, one workspace per task. Nango reports about 200 integrations in 15 minutes for under US$20 in tokens this way, with an orchestrator checking each result.

  6. Before merge: verify what the agent claims

    Does a passing report mean the tests ran?

    What good looks likeCI that reruns the tests, with checks the agent cannot edit. Nango saw agents edit test data, fake API reachability, and report done when they were not, and fixed it with checks after completion.

Questions for Anomaly

  1. Does Enterprise central config reach the desktop app, the web client, and GitHub Actions runs as well as the terminal?
  2. How much notice will Anomaly give before a release changes permission or config behavior?
  3. How are provider keys stored in OpenCode Console after the October 2026 breach?
  4. Which Zen and Go models retain prompts, for how long, and where?

Red flags

  • Engineers install whatever their package manager offers, so versions 1 and 2 coexist on the team.
  • Provider keys are pasted into OpenCode Console with no spend limit.
  • The server is bound beyond localhost with no fixed password: OPENCODE_PASSWORD on OpenCode 2, OPENCODE_SERVER_PASSWORD on 1.x.
  • Agent reports of passing tests are accepted without a CI run.

Products in this piece

Sources

Official documentation
15
Public source
1
  1. OpenCode docs: Intro (OpenCode 1)Official documentationopencode.ai
  2. OpenCode 2 docs: IntroOfficial documentationopencode.ai
  3. OpenCode changelogOfficial documentationopencode.ai
  4. OpenCode docs: EnterpriseOfficial documentationopencode.ai
  5. OpenCode EnterpriseOfficial documentationopencode.ai
  6. OpenCode docs: ConfigOfficial documentationopencode.ai
  7. OpenCode docs: ProvidersOfficial documentationopencode.ai
  8. OpenCode GoOfficial documentationopencode.ai
  9. OpenCode ZenOfficial documentationopencode.ai
  10. OpenCode 2 docs: PermissionsOfficial documentationopencode.ai
  11. OpenCode docs: ServerOfficial documentationopencode.ai
  12. OpenCode docs: SDKOfficial documentationopencode.ai
  13. OpenCode docs: CLIOfficial documentationopencode.ai
  14. OpenCode docs: GitHubOfficial documentationopencode.ai
  15. OpenCode on X: security breach notice (Oct 17, 2026)Official documentationx.com
  16. Nango: What we learned building 200+ API integrations with OpenCode (Apr 1, 2026)Public sourcenango.dev

Keep reading

  1. Buyer guideOpenCode Permission and Sandbox PolicyTurn OpenCode's allow-by-default policy into deny-first rules, secure the server, and decide where agents run in isolation.
  2. ResearchOpenCode in 2026: Security Advisories, Data Paths, and Token OverheadWhere code and keys go when a team runs OpenCode, read from its security advisories, its October breach notice, and its docs, plus public token measurements against Claude Code.
  3. ComparisonQwen Code vs OpenCode: Two Open-Source Agents for the Models You ChooseQwen Code fits teams on Qwen or other open models; OpenCode connects to 75+ model services through Models.dev, with a scriptable server and SSO through Enterprise. Plans, limits, models, data use, admin controls, and one team's monthly bill compared.
Read the research