> For the complete documentation index, see [llms.txt](https://cerebral-systems.gitbook.io/cerebral-systems-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cerebral-systems.gitbook.io/cerebral-systems-docs/agent-integrations.md).

# Agent Integrations

## Supported agents

Warrant manages an agent that is already installed. It does not install the agent, choose a model, create a provider account, or copy provider credentials into a clean runtime.

### Support matrix

| Agent       | Availability                                   | Version contract                                   | Runtime integration                                                  | Assurance                                                                |
| ----------- | ---------------------------------------------- | -------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Claude Code | Demo-ready in public v0.3.0 on macOS           | `>=2.1.20,<2.2.0`; exact detected binary is pinned | PreToolUse hooks plus authenticated Warrant MCP                      | Effective session: `integrated`; profile eligibility ceiling: `brokered` |
| Codex CLI   | Experimental in v0.3.0 on macOS                | Exact `0.144.1`                                    | Closed project config, bounded fail-closed hook wrapper, Warrant MCP | Effective session: `integrated`; profile eligibility ceiling: `brokered` |
| Grok Build  | Current-source preview; not in v0.3.0 Homebrew | Exact `0.2.101`                                    | Empty workspace, hash-bound locked config and Warrant-only MCP agent | Effective session: `integrated`; profile eligibility ceiling: `brokered` |
| Hermes      | Experimental in v0.3.0 on macOS                | Exact `0.18.2`                                     | Exclusive `mcp-warrant` toolset in a clean home                      | Effective session: `integrated`; profile eligibility ceiling: `brokered` |
| OpenClaw    | Experimental in v0.3.0 on macOS                | Exact `2026.7.1`                                   | Native/plugin surfaces closed; exact Warrant MCP allowlist           | Effective session: `integrated`; profile eligibility ceiling: `brokered` |
| PicoClaw    | Experimental in v0.3.0 on macOS                | Exact `0.3.1`                                      | Native tools closed; generated Warrant-only `AGENT.md` and MCP       | Effective session: `integrated`; profile eligibility ceiling: `brokered` |

`integrated` is an application-boundary claim. None of these profiles is `strict_verified` or OS-contained. The `brokered` value is only the profile's maximum eligibility, not the assurance Warrant claims for the current local session.

Linux is a source-preview release target for Codex, Grok Build, Hermes, OpenClaw, and PicoClaw. The current pipeline targets Ubuntu 24.04 and glibc 2.39 on AMD64 and ARM64; it does not establish support for older glibc or musl systems. The public v0.3.0 package remains macOS-only.

Inspect the machine-readable contracts before setup:

```sh
warrant profiles list
warrant profiles show claude-code
warrant profiles show codex
```

`warrant doctor <agent>` is authoritative for the installation in front of you. It reports launch safety separately from model readiness and lists the remaining gaps.

### Claude Code

```sh
command -v claude
claude --version

cd /absolute/path/to/workspace
warrant setup claude --policy read-only
# Follow setup's Next: instruction.
warrant doctor claude
claude
```

Claude is the primary v0.3.0 path. Warrant installs managed PreToolUse hooks and an authenticated local MCP route, closes raw shell and unmanaged MCP authority, and binds the workspace settings to the profile evidence. Selected inert coordination tools can remain available, but file operations use Warrant's typed tools.

On macOS, doctor can check for Claude Code's default Keychain credential presence. It does not read or become the provider credential. Hooks and MCP remain application integration surfaces, not filesystem or network containment.

### Codex CLI

```sh
command -v codex
codex --version

cd /absolute/path/to/workspace
warrant setup codex --policy read-only
warrant doctor codex
codex
```

The adapter generates a closed Codex configuration, installs Warrant's MCP server, and wraps PreToolUse so an internal hook failure becomes an explicit denial. A project `.codex/config.toml` conflicts with this sealed profile and setup fails instead of merging authority.

Only the pinned `0.144.1` contract is accepted. Warrant does not provision Codex model authentication into the clean home, so doctor can report `launch-safe=true` and `model-ready=false`. This is expected for the current experimental adapter.

### Grok Build

> Grok Build support is a current-source preview. The v0.3.0 Homebrew binary does not recognize `warrant setup grok`.

Install Grok separately at the pinned version, then use the narrowest reviewed source policy:

```sh
npm install -g @xai-official/grok@0.2.101
command -v grok
grok --version

cd /absolute/path/to/workspace
warrant policies show privacy-locked
warrant setup grok --policy privacy-locked
# Follow setup's Next: instruction.
warrant doctor grok
grok
```

The managed launch does not give Grok the original checkout as its current working directory. For every session, Warrant creates an empty owner-private workspace and an isolated `GROK_HOME`, then materializes and hash-checks:

* `managed_config.toml`;
* `requirements.toml`;
* `warrant-agent.md`.

The last file is passed through an absolute `--agent` path. Its definition disables default native tools and exposes only the authenticated Warrant MCP tools. This closes both the interactive TUI and headless tool surface under the exact 0.2.101 contract. The launch also selects strict sandboxing, disables memory, subagents, and web search, and applies local upload, telemetry, and trace-upload vetoes.

The shim accepts an interactive launch, read-only diagnostics, or one positional prompt. A prompt is separated from management subcommands before it reaches Grok, so prompt text cannot become `update`, `mcp`, `plugin`, or another authority-expanding mode. Management subcommands are not exposed by the managed shim.

Warrant does not broker Grok OAuth or forward `XAI_API_KEY`. A managed session may require fresh provider authentication, and that state is discarded with the session. The parent Grok process still needs network access for authentication and inference; prompts and file content intentionally read through Warrant still go to the provider. Read Security model: Grok Build before using this preview with sensitive code.

### Hermes

```sh
command -v hermes
hermes --version

cd /absolute/path/to/workspace
warrant setup hermes --policy read-only
warrant doctor hermes
hermes
```

Warrant launches exact Hermes 0.18.2 with the exclusive `mcp-warrant` toolset and an owner-private `HERMES_HOME`. Hermes shell hooks are non-blocking, so Warrant does not treat them as authority. The closed toolset and authenticated MCP session form the application boundary.

Model-provider credentials are not copied into the clean home. The complete Python dependency tree is not sealed, and the host filesystem and network are not contained.

### OpenClaw

```sh
command -v openclaw
openclaw --version

cd /absolute/path/to/workspace
warrant setup openclaw --policy read-only
warrant doctor openclaw
openclaw "Review README.md"
```

The exact 2026.7.1 adapter disables plugin discovery, hooks, channels, native execution, and non-Warrant tools. It replaces those authority-bearing sections rather than merging user configuration, then exposes the five Warrant MCP tools through an exact allowlist. An owner-private exec-approval policy also denies raw execution.

The no-argument managed command shows help; provide one positional prompt to run the local agent path. Warrant does not provision OpenClaw model credentials.

### PicoClaw

```sh
command -v picoclaw
picoclaw version

cd /absolute/path/to/workspace
warrant setup picoclaw --policy read-only
warrant doctor picoclaw
picoclaw
```

The exact 0.3.1 adapter creates a clean PicoClaw home, disables native read, write, execution, web, skill, subagent, and device tools, and generates a Warrant-only `AGENT.md` and MCP configuration. PicoClaw's interceptor hooks can fail open, so they are disabled rather than trusted as the boundary.

PicoClaw 0.3.1 has no macOS child-process isolation backend. Model credentials are not provisioned into its clean runtime.

### Managed argument bounds

The shims intentionally accept a narrow launch grammar: normal interactive use, a small set of read-only diagnostics, or one positional prompt where the adapter supports it. Agent subcommands and flags that could replace configuration, tools, workspace, permissions, or MCP routing deny at the shim.

Run provider login, update, plugin management, or other administrative tasks outside a managed Warrant session, then repeat setup so Warrant can review and bind the resulting agent version. Direct use of the original binary is outside the Warrant boundary.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cerebral-systems.gitbook.io/cerebral-systems-docs/agent-integrations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
