Supported
Enrolled Mimir implements the specified signed-policy check at its native gate.
Agent support
Check the capability your team actually needs.
Match a required operation to its client integration, minimum version, activation conditions, and known gaps.
Client names do not describe control coverage. Use the action, execution boundary, and installed version to decide whether a setup meets your requirement.
01 / Agent support
Separate capability from a working installation.
A supported adapter feature can remain inactive on a particular device. Trust, version compatibility, release availability, and event binding still matter.
A lifecycle boundary is the point where a client invokes a hook or native check. Different actions can use different boundaries.
Tool authorization does not establish model authorization. A familiar action name also does not make an unsupported catalog binding usable.
Use the matrix to prepare an evaluation question. Record the operation your team needs and which coverage state it can accept.
Harbor and its Search team are imaginary examples. If Search needs a shell restriction, the team should test that boundary on its actual client.
A required rule cannot supply missing adapter support. The correct result may be a conditional pilot, another runtime, or a revised deployment approach.
Claude Code and Codex have native integrations independent of Mimir. Choosing Mimir creates a separate runtime path; it does not upgrade another client's hooks.
Conditional
A covered path and active integration are necessary. Execution and report delivery still have stated limits.
Guidance only
The client receives instructions without a guarantee of compliance or exclusion of unmanaged skills.
Not yet supported
This adapter lacks the specified implementation. Configuration requirements do not change that state.
02 / Agent support
Use the implemented support contract.
The following rows describe the shared implementation contract. They are not confirmation that a public package or your local activation is ready.
Inspect event-specific bindings when a row is conditional. Their narrower boundary can determine whether a proposed rollout is appropriate.
| Requested capability | Claude Code | Codex | Enrolled Mimir |
|---|---|---|---|
| Allowed tools | Conditional: local hook boundary | Conditional: local hook boundary | Supported, 0.21.0+ |
| Allowed shell programs | Conditional: literal executable gate | Conditional: literal executable gate | Supported, 0.21.0+ |
| Approved models | Conditional: explicit switches, 2.1.251+ | Not yet supported | Supported, 0.21.0+ |
| Maximum reasoning level | Not yet supported | Not yet supported | Supported, 0.21.0+ |
| Approved skills | Guidance only | Guidance only | Guidance only |
| Session activity | Conditional: reports from the client | Conditional: reports from the client | Conditional: reports from the client |
| Duration measurement | Not yet supported | Not yet supported | Conditional, 0.22.0+ |
| Tool failure notice | Conditional: completion hook | Not yet supported | Conditional, 0.22.0+ |
| Resource usage | Conditional: Betterloop adapter 0.8.0+ | Not yet supported | Not yet supported |
03 / Agent support
Understand what the shell gate evaluates.
The shell check parses a literal executable with its arguments. That executable must satisfy every applicable organization and team restriction.
The containing tool has a separate permission check. An approved executable cannot make a restricted tool available.
Supported parsing preserves quoted glob patterns, escaped spaces, and empty arguments. It evaluates their literal meaning without model interpretation of the command.
Ambiguous forms are rejected. Examples include command substitution, redirects, environment prefixes, executable paths, and shell control constructs.
An approved program can run code or launch other programs. The hook therefore does not provide complete process containment.
Existing sessions and hosted tools sit outside this native gate. Native hook errors or timeouts can also permit execution according to host behavior.
Use separate calls for pipelines or chained commands. Investigate a rejected construct instead of hiding its executable inside another invocation.
For Search, allowing rg can support a literal documentation search. That result does not establish containment of every operation performed elsewhere.
rg -g '*.md' docs
rg -n "params|searchParams" src/app04 / Agent support
Treat model selection as its own requirement.
Claude Code supports the conditional PreModelSwitch integration on compatible versions. It can reject an explicit model change that the configuration does not permit.
The boundary does not cover startup, resume, automatic fallback, or subagent selection. Those cases require the native managed model settings.
Codex model restrictions are not implemented by this adapter. A preferred model in an ordinary settings file does not create an enforced restriction.
Maximum reasoning controls are also absent from the Claude Code and Codex adapters. A requested effort setting remains guidance in those integrations.
Enrolled Mimir checks supported model and reasoning restrictions at native runtime gates. Confirm its feature-specific version requirements before selecting that path.
Claude resource usage reports have another boundary. Trusted hooks can report skill identifiers, MCP server or tool names, and subagent types without their inputs.
Delivery of those resource events is best effort. Missing reports cannot establish that a resource was never used.
05 / Agent support
Prepare the device and prove activation.
Setup needs Node.js 22 or newer, npm, a Git repository, and an administrator-issued enrollment code. Client authentication remains a separate native step.
Supported macOS connections use a shared MCP OAuth proxy with Keychain storage. New Linux OAuth and Windows device setup are deferred.
Optional resources need Mimir 0.26.0+. Unknown-repository behavior requires setup 0.7.0+ and Mimir 0.27.0+; these are distinct feature floors.
Installing plugin files does not demonstrate invocation. Complete native trust or reload requirements, then begin a fresh session in the selected repository.
Use Doctor to inspect activation and required coverage gaps. Repeat the behavior check after client upgrades or changes to the integration.
- 01
Identify the test boundary
Record the required operation, client version, event binding, and setup version.
- 02
Inspect the runtime release
Check the signed artifact for compatibility, expiry, and known revocations.
- 03
Complete native preparation
Finish client sign-in. Review Codex hooks in /hooks. Complete trust. Begin a fresh session.
- 04
Read diagnostics
Run Doctor for the selected integration.
- 05
Test actual behavior
Try one agreed permitted operation. Try one agreed prohibited operation. Record whether each operation ran.
- 06
Compare local and reported results
Investigate discrepancies between the test and Connections.
npx @betterloop/setup doctor --harness codex06 / Agent support
Use symptoms to locate the next check.
Do not repair every issue by editing policy. Authentication, release production, native activation, and report delivery have different owners and failure conditions.
Retain the tested versions with the result. A later upgrade can change activation requirements even when the selected rule has not changed.
| Symptom | Investigate first | Conclusion to avoid |
|---|---|---|
| Files present without activation evidence | Host trust, reload behavior and a fresh session | Every installed integration is running |
| Valid configuration with missing support | The action, event, catalog and runtime version | Mandatory text creates a host capability |
| MCP connection without usable tools | Service sign-in and actual tool discovery | Configuration files grant external access |
| No usable signed policy | The runtime variant, expiry and sync result | A merged change is already a release |
| No reported session event | Covered hooks and delivery diagnostics | An absent event means no activity |
Can one enrollment enable several agents?
Yes. Selected agents share the device connection to one organization and team. Each client still needs its own native authentication and trust.
Will installing Mimir fix a missing Codex control?
No. Its native gates apply to work performed through Mimir. Codex retains the capabilities and limits of its own integration.
How should we evaluate conditional support?
Name the exact boundary, test actual behavior, and record uncovered paths. Decide whether that result meets the requirement before expanding deployment.