Self-hosted infrastructure for a fleet of long-lived AI agents. Each agent runs in its own sandboxed container with a persistent workspace, internet access, and a pluggable driver.

Yes. Single-VM deploy on plain Docker with your own keys and data. No vendor lock-in, no per-seat SaaS tax, nothing leaves your stack.

Which agent engines (drivers) are supported?

One identical API across swappable brains: Vanilla, Opencode, Codex, and Claude Code. The driver is part of an agent's config and can be swapped anytime.

How do you keep my data and agents secure?

Every agent runs in a hardened container: read-only root filesystem, dropped capabilities, network egress filtering, and CPU/memory limits. LLM keys are stored server-side, encrypted, and never sent to the browser.

Can I watch what an agent is doing?

Yes. Every task streams over Server-Sent Events (assistant messages, tool calls, results, file changes, a live token meter), and reconnects resume where they left off.

Accounts are provisioned by admins; you self-host the stack. Use Get started, or sign in if you already have an account.

GitHub CLI vs GitHub MCP for Claude Code Workflows

The short answer: for most developer-owned Claude Code sessions, start with gh. It is already tied to the local checkout, uses familiar GitHub authentication, and leaves GitHub work visible as shell commands. Use GitHub MCP when you want Claude Code to work through typed GitHub tools for issues, pull requests, labels, Actions, security findings, or cross-repo work. Use a gateway when the work is shared, non-human, audited, or policy-sensitive.

That is the practical answer to GitHub CLI vs GitHub MCP for Claude Code. The choice is less about which interface is more modern and more about where you want the control boundary to sit.

If the actor is a developer in a local repository, gh usually fits the operating model. If the actor is an agent doing triage, support automation, release coordination, or background PR work across repositories, the platform team should prefer GitHub MCP with narrow toolsets or a custom gateway backed by GitHub App credentials.

Related reading: Claude Code hooks and permission controls.

GitHub CLI vs GitHub MCP for Claude Code: the decision frame

You are choosing between four access paths, not two:

git and gh through Claude Code Bash permissions.
GitHub MCP as a local stdio server.
GitHub MCP as a remote server.
A gateway that exposes only the GitHub operations your team approves.

The security question is not "CLI safe, MCP risky" or the reverse. Both can act with real GitHub credentials. Both can read private code if the token can read private code. Both can mutate issues, branches, pull requests, workflows, or repository settings if the surrounding permissions allow it.

The difference is shape. gh is a shell command interface. GitHub MCP is a typed tool interface. A gateway is a policy interface.

Option	Best fit	Main risk	Control point
`gh`	Local repo work, PR viewing, PR checkout, issue lookup, branch pushes, developer-driven PR creation	Bash access can be broad unless command patterns, hooks, or wrapper scripts constrain it	Claude Code Bash rules, shell environment, GitHub token, branch protection
GitHub MCP	Structured issue, PR, label, Actions, repository, organization, and security workflows	Too many visible tools or write tools exposed for too long	MCP toolsets, read-only mode, Claude Code MCP approvals, token permissions
Gateway	Shared agents, CI-like runs, support triage, background automation, regulated environments	Higher build and maintenance cost	Server-side policy, short-lived GitHub App tokens, custom audit, approved operations

Why `gh` is usually the default for local Claude Code

Claude Code already has a shell. In a developer-owned checkout, gh benefits from that fact.

Commands such as gh pr view, gh pr checkout, gh issue list, gh api, and gh pr create naturally inherit the current directory, the repository remote, the active branch, and the developer's existing authentication. The model does not need to learn a separate owner and repository parameter for every operation. The transcript also shows the command that was run.

That transparency matters to engineers. A platform engineer reviewing an agent session can see whether Claude Code ran gh pr view 123, gh pr merge, or gh api against a write endpoint. MCP calls can be logged too, but the operational detail depends on the host's tool-call logging and how much input and output is retained.

The trade-off is that gh sits behind Bash. Claude Code permission rules can approve or deny Bash patterns, but gh is still part of a larger shell surface. If your team allows broad Bash access, gh is not the only GitHub-relevant capability in scope. The agent can also run git push, edit remotes, call APIs through scripts, or use tokens from the environment.

GitHub CLI authentication is also worth treating carefully. The GitHub CLI manual documents minimum classic personal access token scopes for gh auth login --with-token as repo, read:org, and gist. GitHub recommends GH_TOKEN when using fine-grained personal access tokens with gh. GitHub's token documentation also notes that classic PATs are less secure because they can grant access to all repositories the user can access, while fine-grained PATs can be limited by owner, repositories, and permissions.

Implication: gh is operationally simple, but it should not become an unmanaged exception to the team's credential policy.

Where GitHub MCP is stronger

GitHub MCP gives Claude Code a named GitHub tool surface. The official GitHub MCP server is designed to let agents read repositories, manage issues and pull requests, analyze code, and automate workflows. Its default local toolsets include context, repos, issues, pull_requests, and users. Other available toolsets include actions, labels, orgs, projects, code_security, and secret_protection.

That matters when the work is wider than the current checkout. A triage agent might need issues, labels, and pull requests but no repository write tools. A security-review agent might need code security and secret protection surfaces but no issue creation. A release agent might need pull request metadata and Actions status, while branch protection still requires human review before merge.

MCP lets the platform team expose a smaller GitHub vocabulary to the model. The GitHub MCP server supports narrowing the tool surface with --toolsets, GITHUB_TOOLSETS, --tools, GITHUB_TOOLS, and exclusion controls. Its docs explicitly recommend enabling only the needed toolsets to improve tool choice and reduce context size.

Read-only mode is the key control for early adoption. GitHub MCP read-only mode disables write tools even when a writable toolset is requested. The server configuration docs give a concrete example: create_issue is excluded even if the issues toolset is enabled.

Related reading: MCP tool allowlists and drift detection.

The hidden catch: tool visibility is not token permission

A common implementation mistake is to treat visible MCP tools as the same thing as authorized GitHub actions. They are different layers.

Claude Code permissions decide which tools the model can see or auto-approve. MCP server configuration decides which GitHub MCP tools exist in the session. GitHub credentials decide what the API will actually allow. GitHub organization policies, SSO, branch protection, and GitHub App installation permissions can still block or constrain the request.

The GitHub MCP scope-filtering caveat is important. Scope filtering works best with classic PATs because OAuth scopes are visible. For fine-grained PATs, GitHub App installation tokens, and other server-to-server tokens, the GitHub MCP docs say scope filtering is skipped because the server does not receive X-OAuth-Scopes. In that case, GitHub API authorization enforces permissions at call time.

Consequence: if you use fine-grained PATs or GitHub App tokens, you should still constrain MCP toolsets and tools directly. Otherwise Claude Code may see tools that fail with authorization errors. That is usually safer than over-permissioning the token, but it creates noisy sessions and less predictable agent behavior.

Claude Code permissions: availability is not approval

Claude Code has its own permission model, and teams should separate two concepts:

Tool availability: whether a tool is present in the model context.
Tool approval: whether a tool call can run without asking.

Anthropic's permission docs distinguish these. Denying a bare tool name such as Bash or mcp__* removes matching tools from context. By contrast, allowed_tools auto-approves listed tools but does not make every unlisted tool unavailable.

This is a serious difference. A team might believe it has built an allowlist while it has only removed prompts for certain tool calls. For high-risk modes, the distinction is sharper: Anthropic documents bypassPermissions as auto-approving tool uses and giving Claude full system access, while allowed_tools does not constrain that mode. Deny rules and hooks still matter.

For project MCP servers, Claude Code also requires trust and approval. A cloned repository cannot approve its own .mcp.json servers. User or managed settings still control approval. That is the right default for platform teams, because a repository-level MCP config can otherwise become a supply-chain control plane.

When a gateway is the better answer

A gateway is justified when the workflow should not inherit one person's broad GitHub session.

Examples:

A support triage agent labels issues across several private repositories.
A release assistant reads Actions status and opens release PRs but never merges.
A background Claude Code process comments on stale pull requests.
A security workflow reads secret scanning and code scanning alerts without repository write authority.
A central platform service needs audit records that map every action to an internal policy decision.

In these cases, exposing broad Bash plus gh is too coarse. Exposing the full GitHub MCP server may also be more surface than the workflow needs. A gateway can combine narrower operations with better defaults: current-repository resolution, server-side policy checks, short-lived GitHub App installation tokens, dry-run write paths, and logs designed for incident response.

The cost is real. A gateway needs engineering ownership, versioning, monitoring, and a permission model. But once the agent is shared across teams, that cost often replaces a larger hidden cost: debugging who approved which GitHub action, through which token, from which machine, under which Claude Code settings.

Recommended patterns by workflow

Workflow	Recommended interface	Reason	Guardrail
Developer asks Claude Code to inspect a PR in the current repo	`gh`	Fast, local-context aware, visible command transcript	Allow read commands, prompt or deny merge and delete patterns
Developer asks Claude Code to open a PR from local branch changes	`gh`	Fits local branch and remote state	Require human approval for push and PR creation in sensitive repos
Agent triages issues and labels across repositories	GitHub MCP or gateway	Typed issue and label operations are easier to restrict	Expose only issues and labels, prefer read-only first, then add selected writes
Agent reads Actions failures and summarizes likely cause	GitHub MCP	Actions toolset can be exposed without full shell authority	Read-only mode unless reruns or workflow dispatch are explicitly approved
Security agent reviews code scanning or secret scanning signals	GitHub MCP or gateway	Security toolsets can be separated from repository mutation	Use narrow token permissions and audit every lookup
Non-human automation comments on PRs or opens issues	Gateway backed by GitHub App	User PATs are a poor fit for long-lived shared automation	Use short-lived installation tokens and server-side policy

A practical rollout plan

Scenario A: individual developer enablement. Keep gh available for ordinary local workflows. Define Bash rules for obvious high-impact operations such as repository deletion, destructive API calls, direct merges, and force pushes. Use GitHub's normal branch protection and review rules as the final backstop.

Scenario B: team MCP pilot. Add GitHub MCP with read-only mode and only the toolsets required for the workflow. For example, start with issues and pull_requests for triage, or actions for CI inspection. Do not expose organization, project, code security, or secret protection toolsets unless the use case needs them.

Scenario C: shared automation. Build or buy a gateway when the actor is no longer an individual developer. Use GitHub Apps for organization access or long-lived integrations, which GitHub recommends for scalability and management. Avoid treating a human PAT as shared infrastructure.

For each scenario, document four things:

Which Claude Code tools are available.
Which tool calls are auto-approved.
Which GitHub credential type is used.
Where audit records live.

This is where many pilots fail. Teams configure a GitHub interface, but they do not write down the permission stack. Later, when an agent cannot label an issue or can see a tool it cannot execute, nobody knows whether the cause is Claude Code settings, MCP configuration, token scope, SSO, branch protection, or GitHub App installation permissions.

Pilot checklist

Before you standardize on gh, GitHub MCP, or a gateway, test the failure modes that matter in your environment:

Can Claude Code read private repository data only where expected?
Can it create issues, labels, comments, branches, and pull requests only where expected?
What happens when the token lacks permission but the MCP tool is visible?
Are MCP write tools removed in read-only mode?
Are project-level MCP servers blocked until explicitly trusted?
Are allowed_tools, deny rules, and hooks tested together?
Does bypassPermissions exist anywhere in wrappers, scripts, or team guidance?
Do audit logs show enough detail for a real incident review?
Does the remote GitHub MCP server fit your GitHub Enterprise Server or residency requirements?

The GHES point deserves special attention. The briefed GitHub docs say remote server hosting is not supported for GitHub Enterprise Server, while the local server can target GHES. That difference can decide the architecture for regulated or self-hosted GitHub environments.

Decision summary

Use gh when Claude Code is assisting a developer inside a local checkout and the work is easy to inspect as commands. It is the lowest-friction path for PR viewing, branch work, issue lookup, and repo-local tasks.

Use GitHub MCP when you want a typed GitHub API surface, especially for issue, PR, label, Actions, repository, organization, or security workflows. Constrain it with toolsets, individual tools, read-only mode, Claude Code deny rules, and narrow GitHub credentials.

Use a gateway when the workflow becomes shared, non-interactive, cross-repo, or policy-heavy. That is where server-side enforcement, GitHub App installation tokens, and custom audit are worth the extra engineering cost.

The mature platform posture is not one interface everywhere. It is a tiered model: gh for local developer work, constrained GitHub MCP for typed read and limited write workflows, and a gateway for shared automation.