OpenRig can start an agent team. Who trusts the workspace?

A development team wants to try two coding agents on a small change. One will implement it and the other will check the result. Starting a team looks like a short terminal exercise. But the trial machine also hosts other repositories. The same user account holds provider configuration and workspace trust records. Before either agent changes a line of code, the real question is already different: where does this team end, and where does the rest of the machine begin?

OpenRig is an open-source system for running coding agents such as Claude Code and Codex together. It provides a local daemon, tmux sessions, SQLite-backed state, a CLI and a terminal interface. A team can be described in YAML; stable seat addresses let people route work to a role rather than a disposable terminal window. Our earlier OpenRig article looked at the difference between sending a message and assigning owned work. Here the concern is what happens to the working environment before that assignment starts.

A team definition is not a machine boundary

A RigSpec describes the team’s members and connections. To run it, however, the coding agents must launch, recognize the repository as a trusted workspace and communicate with OpenRig. The project’s documentation distinguishes setup, daemon startup and seat launch for a reason. Some changes happen in the provider’s own files, not just inside OpenRig’s state directory.

For instance, daemon startup can write Codex activity hooks and trust records. Launching a seat can mark its workspace trusted. On the Claude Code side, startup may also affect workspace settings, activity collection and selected resources. None of this proves that the software automatically grants unrestricted access to every file. It does mean that “we only opened another terminal” is not an adequate description of the trial. A team needs to know which settings it touched and which other jobs share those settings.

The documented rig setup --dry-run helps inspect the setup plan. The project also notes that this preview does not cover every later daemon or seat-startup effect. A clean-looking setup preview is therefore not proof that the user account’s configuration will remain untouched. That matters especially on a shared engineering machine or a host used for multiple client repositories.

A narrow coding trial

Consider an internal search interface that displays the wrong text when a query returns no results. The requested change is small. An owner seat will implement it; a checker seat will review the candidate. Before choosing which model belongs in each seat, the team should decide which operating-system account will run them. What else can that account read? Are provider settings shared with other projects? Where will the test output and review decision live?

These questions are easy to miss when the checker is described as a limited role. The checker might be intended to see only the relevant diff and test result. If both seats run under the same user account, the checker may still have technical access to unrelated project directories. A seat name is a routing address and a statement of intent. It is not an operating-system permission boundary. Giving the roles different names does not place them in different security zones.

A separate trial environment makes the boundary easier to inspect. The team can identify its provider account, accessible repositories and network permissions in advance. It can record the configuration before launch and compare it afterward. rig ps --nodes can show whether seats are ready; readiness does not say whether their effective access matches the intended roles. That requires a separate review of files and provider settings.

There is also a financial boundary. OpenRig can be self-hosted and open source while the underlying models still incur provider costs. More seats mean more simultaneous sessions that may draw on the same account or limits. The person accountable for those costs should be as clear as the person accountable for merging the change.

A trusted workspace is not a trusted instruction source

OpenRig reduces a real coordination burden. People can see a team topology, address a stable role and return to running sessions without guessing which anonymous terminal owns a task. But a convenient launch does not amount to an organization-wide policy. A seat allowed to edit code does not necessarily have authority to merge or deploy. Marking a repository trusted for a coding tool also does not make every piece of text inside it a valid instruction to the agent.

A README, a third-party package response or a page fetched during investigation may contain directions that conflict with the actual assignment. Those materials are task data until the responsible human chooses otherwise. If an agent treats all encountered text as equally authoritative, a perfectly organized team can perform the wrong work with impressive coordination. Review should therefore cover both the machine permissions and the boundary between the human task and lower-trust source material.

The OpenRig documentation distinguishes its shipped permission behavior from broader access that an operator might choose explicitly. That distinction is useful, but each organization still needs its own acceptance criteria. Which files may this agent change locally? Can it move to another repository? Which external destinations may it write to? Who can approve a merge or deployment? If those answers remain implicit, the next trial might start in the same environment with permissions nobody intended to reuse.

What to verify after the trial

Start with one repository and one bounded change. Before launching, inventory the provider configuration and workspace trust records relevant to the chosen user account without copying secret values. Inspect the setup plan, then compare the same settings after the daemon and seats are running. Remove permissions that the trial does not need, or repeat it under a narrower account. A production repository should not be the place to discover the launch effects for the first time.

At the end, ask for two separate results. The first concerns the work: which candidate was reviewed, which tests ran against it and who accepted it? The second concerns the environment: which configuration changed, which changes were rolled back and which were intentionally retained? A code review answers the first question; an environment review answers the second. Combining both into “the agent completed the task” leaves the next trial exposed to assumptions inherited from this one.

OpenRig gives coding agents a concrete way to operate as a visible team; workspace trust and company authority still need their own definitions. For the wider layer of roles, skills and policies, agentic-organization is a self-hosted, file-based platform for managing AI agents as first-class members of an organization chart.