Integrations

Connect agents to tools with clear credential boundaries.

Start with GitHub and MCP clients, where setup, credential custody, and outputs are easiest to inspect. The tested MCP setup path today covers Codex CLI, Claude Code, and OpenCode.

Integration shape

The setup, credentials, governed actions, and evidence should be obvious.

Compatibility

Grounded today: GitHub boundaries plus tested MCP registration and bearer-authenticated connectivity for Codex CLI, Claude Code, and OpenCode.

Agent loop

An ExecWarden-hosted session or the connected client owns the reasoning loop. A separate execution environment supplies machine access when needed.

Credentials

Provider credentials can stay in ExecWarden instead of being copied into the agent environment.

Governed actions

GitHub, package-backed tools, imported MCP tools, approvals, expiry, revocation, and activity records can follow the same boundary model.

Start

Pick a client or provider path with a clear first task and a boundary to inspect.

Choose by boundary

Choose the client or provider path with the clearest boundary first.

Each integration should make the agent loop, credential path, governed actions, and post-run evidence clear.

MCP clients

Codex CLI, Claude Code, OpenCode, and other compatible MCP clients.

Use ExecWarden's MCP endpoint to put a scoped Agent identity between the client and the capabilities it may call.

GitHub

The first concrete system to try.

Repo allowlists, branch patterns, PR review, separate merge authority, approvals, and activity records make the boundary understandable.

Packages and imported MCP

Add internal APIs and SaaS tools when the boundary is clear.

Package-backed tools and imported MCP tools can use the same scoped grants, approvals, and activity records.

Where teams start

Concrete first integrations to try.

1GitHub governed repo work.
2Linear package-backed issue writes.
3Incident-demo paths that name exactly which providers are live, fixture-backed, or package-backed.

Integration details

Every integration should make the boundary clear.

For each client, provider, or execution environment, the important questions are the same:

Where does the agent loop run?
Where do tools execute?
Which credentials are used?
Which actions can ExecWarden govern?
What appears in ExecWarden afterward?
How does a user start?

Choose an integration path

Start with one client or provider that makes the boundary obvious.

GitHub and MCP clients are usually the clearest first proof because the inputs, outputs, and credentials are easy to inspect.

Start with GitHubRead docs