Grant GitHub Push Access to a Sandboxed Agent
This tutorial shows how provider access and sandbox policy work together. You attach a GitHub provider that contributes read-only GitHub access, observe a denied push, and add a user policy that permits writes to one repository.
The built-in default policy does not grant network access. Imported provider profiles contribute the endpoints and executable paths needed by their providers.
Prerequisites
You need:
- A working OpenShell installation and active gateway.
- An OCI image you built with Claude Code,
git, and the GitHub CLI installed. - An Anthropic API key.
- A GitHub fine-grained personal access token with read and write access to the target repository’s contents.
- A scratch GitHub repository that you can push to.
Use two host terminals. Terminal 1 runs the agent. Terminal 2 inspects denials and updates policy.
Import the Provider Profiles
Review the Claude Code profile
and GitHub profile.
Confirm that their binaries paths match the executables in your image, then
import them directly. If a path or endpoint grant needs to change, edit a local
copy and import it with -f instead.
The gateway contains no built-in profiles. Import each profile once per gateway at the scope where users need it.
Create the Providers
Create provider instances from credentials in your host environment. Passing a credential on the same command line exports it only to that command:
OpenShell stores the credentials through the configured credential driver. The agent receives opaque placeholders; the sandbox proxy resolves them only for endpoints allowed by the corresponding profile.
Start the Agent
In terminal 1, start Claude Code from your image and attach both providers:
To use an existing sandbox, attach the providers from a host terminal, then start a new agent process so it receives the provider environment variables:
Attempt a Push
Ask the agent to create a file and push it to your scratch repository. Replace
<org> and <repo> with the repository owner and name:
The push fails. The GitHub profile permits clone and fetch operations but does
not permit git-receive-pack, the Git Smart HTTP operation used for a push.
The credential remains attached and endpoint-scoped; changing the token would
not grant the missing network authority.
Inspect the Denial
In terminal 2, inspect recent sandbox logs:
You should see a denial for a request resembling this one:
_provider_my_github is the rule that OpenShell composes from the attached
my-github provider. Policy events are INFO-level log records, so do not filter
them out with --level warn.
You can also run openshell term to inspect policy decisions in the terminal
dashboard.
Create a Repository-Scoped Policy
policy set replaces the complete base policy, so start from the sandbox’s
current one. In terminal 2, print it:
The command prints revision details followed by the policy. Save only the policy
YAML as github-push.yaml. Keep its filesystem, Landlock, and process settings
unchanged, because OpenShell rejects removed filesystem paths and changed
Landlock or process settings on a running sandbox.
Add these entries under network_policies, creating the section if it is
missing. Replace <org> and <repo>, and adjust binaries to match your
image:
The first entry grants Git Smart HTTP operations only for the selected
repository. The second lets gh use REST operations scoped to the same
repository. The attached GitHub provider continues to supply credential
placement and its broader read-only rules.
Apply the Policy
Apply the policy and wait for the new revision to load:
Network policy changes hot-reload without recreating the sandbox. Provider rules are composed with this user-authored base policy.
Next Steps
- Review Profiles for endpoint-scoped credential placement.
- Review Manage Sandbox Policies for incremental policy updates and policy history.
- Review the Policy Schema for REST, GraphQL, and other protocol rules.