Prepare the company connection
Publish organization rules, team inheritance, and the first repository assignment.
Open this resource →Betterloop handbook
From a team decision to a working session
Instructions for connecting people, reviewed rules, and repository knowledge to the coding agents your team uses.
A device connection is the starting point. These guides help you follow a reviewed configuration into an actual repository session.
01 / Betterloop handbook
Choose the work you need to complete
Enroll this device
Connect once, select agents, and inspect a repository session.
Open this resource →Claude Code connection
Set up the plugin and check the events it supports.
Open this resource →Codex connection
Complete native trust and inspect the resulting integration.
Open this resource →Optional Mimir connection
Select the runtime and its available provider access route.
Open this resource →Find and repair a failed connection
Match a diagnostic result to the state that needs attention.
Open this resource →Look up a command
Find accepted options, local locations, and support terminology.
Open this resource →Complete a specific task
Follow recipes for resources, authorization, verification, and shared learning.
Open this resource →An administrator prepares the organization and team releases. A developer connects a device to those releases. Neither person completes the entire process alone.
Begin with your part of that handoff. The client guides then explain what changes for Claude Code, Codex, and optional Mimir.
02 / Betterloop handbook
A useful order for the first connection
For the person who owns the rollout
Identify the first team and its configuration repository. Review the organization rules. Publish the approved revision. Then prepare the team release.
Assign a working repository through the reviewed team configuration. Invite one developer. Check the resulting session before you expand the rollout.
One organization owns one configuration. Each team also owns one configuration. Drafts, review submissions, and published releases describe versions of those configurations.
For the person who writes code
Open your team invitation. Obtain the personal enrollment command. Select the agents you intend to use on this device.
Complete provider sign-in inside each selected agent. Review any native hook trust request. Start a new session in the assigned repository.
Use doctor to inspect that specific agent and repository. Read the individual results before you tell the team that setup is complete.
For an existing connection with a problem
Record the affected repository and agent first. Read status. Run doctor for that combination. Identify the failed part of the connection.
A provider account problem needs native sign-in. A stale release needs refresh. An inactive plugin needs an activation check. These repairs change different state.
03 / Betterloop handbook
The vocabulary behind the connection
| Name in these guides | What it refers to |
|---|---|
| Coding agent | The application that works on your task. Betterloop commands select it with the harness flag. |
| Enrollment | A device authorization for one organization and one team. Repositories use that existing device connection. |
| Rules configuration | The organization or team record whose revisions move through drafting, review, and publication. |
| Signed release | A reviewed version whose signature and scope the client validates before applying it. |
| Hook | An integration called by the coding agent at a particular supported event. |
| Coverage | A control-specific description of support for the installed agent version and observed execution event. |
| Client | The installed coding agent that consumes the applicable Betterloop release. |
| Adapter | The integration code that connects Betterloop behavior to one agent. |
| Runtime gate | A check performed at a supported action before that action proceeds. |
| Baseline | The reviewed organization revision selected by a team for inherited rules. |
| Registry | The versioned collection containing approved resource files and descriptive metadata. |
| Resource | A skill, instruction, reference, hook, or rule available through the approved collection. |
| Digest | A calculated content value used to identify the exact file bytes. |
| Learning entry | A lesson with review history, applicability, and evidence for its proposed use. |
| Learning pack | The signed delivery collection containing eligible learning entries. |
| Cohort | The set of recipients assigned to a stage of release delivery. |
| Canary | The first small recipient group used to check a release before expansion. |
| MCP | Model Context Protocol, used for connections to external tools and resources. |
| OAuth | An account authorization flow that provides scoped access to another service. |
| Attestation | Independent evidence about a device. A report produced by the connected client does not provide this independence. |
04 / Betterloop handbook
What you can conclude from a result
Installation establishes that the selected software is present. Authentication establishes provider access. Signed release validation establishes the applicable reviewed configuration.
Activation requires an observed supported invocation. Coverage describes the controls available at the relevant events. Check these results individually.
A conditional result names requirements that must hold during execution. An advisory result supplies instructions without a guaranteed blocking check.
A required control without adapter support prevents acceptance as fully governed. Discuss a compatible client or a changed rollout requirement with the administrator.
The initial examples use npx @betterloop/setup. Later examples use betterloop when your approved installation provides that command.
You can connect only Claude Code, only Codex, or both. Mimir is a separate optional runtime. The native integrations do not require it.
Keep the native agent documentation available. It remains the reference for provider sign-in, host permissions, managed settings, and native trust.