Skip to main content

Use your own subscription

By default, Agenta runs agents with a model API key it resolves for each run. You can instead run agents with your own harness subscription: a Pi login, a Claude Code login, or a ChatGPT/Codex login.

A subscription authenticates the harness through a directory mounted into the runner container, so it works only with local runs. Agenta never uploads the login to a Daytona sandbox, and a Daytona run cannot use one.

This tutorial mounts your login into the runner container and runs an agent that uses it.

This is for a single trusted operator

One personal subscription serves one operator, not every user of a shared deployment. Every local run can read the files mounted into the runner container, including this login. Use this only on a deployment you run for yourself. See Sandbox isolation and security.

Before you start​

  • A running local OSS stack. See the Quick start.
  • A harness you have logged into on your own machine:
    • Pi stores its login at ~/.pi/agent/auth.json. Log in with pi, then /login.
    • ChatGPT / Codex uses the same Pi login file. Log in with pi, then /login, and pick the ChatGPT sign-in.
    • Claude Code stores its login at ~/.claude/.credentials.json. Log in with claude and pick the subscription login.

1. Confirm the login on your machine​

Check that the login file exists before you mount it:

# Pi and ChatGPT/Codex
ls ~/.pi/agent/auth.json

# Claude Code
ls ~/.claude/.credentials.json

2. Mount the login into the runner​

Edit the runner service in your Compose file (hosting/docker-compose/oss/docker-compose.gh.yml). Add a read-write volume for your login and point the harness at it.

For Pi or ChatGPT/Codex:

runner:
  volumes:
    - ~/.pi/agent:/agenta/harness/pi:rw
  environment:
    PI_CODING_AGENT_DIR: /agenta/harness/pi

For Claude Code:

runner:
  volumes:
    - ~/.claude:/agenta/harness/claude:rw
  environment:
    CLAUDE_CONFIG_DIR: /agenta/harness/claude

The mount is read-write, and the harness runs directly out of it. Subscription logins are OAuth logins: the harness refreshes its own access token during a run and writes the new one back to the mount. Because the mount is writable, that refreshed token persists to your login on the host, so runs keep working after the provider rotates a token and you never have to log in again by hand. This is exactly how the harness behaves when you run it on your own machine.

Two consequences:

  • The harness writes to your login directory. It refreshes tokens there, and a run that carries skills or a system prompt installs them there too.
  • Concurrent local subscription runs share that one directory, the same way two claude or pi sessions on your laptop do. This path is for a single trusted operator, not a shared deployment.

Recreate the runner so it picks up the change:

docker compose -f hosting/docker-compose/oss/docker-compose.gh.yml \
  --env-file hosting/docker-compose/oss/.env.oss.gh up -d runner

3. Run a self-managed agent​

In the studio, run an agent and choose the self-managed credential option (use your own login) for the matching harness. The run authenticates with your mounted subscription instead of a managed key.

4. Confirm the mount is required​

Remove the volume and environment lines you added in step 2, recreate the runner, and run the same agent again. The run fails because the harness has no login to authenticate with. This confirms the run used your mounted subscription and not a hidden credential.

Restore the mount to go back to using your subscription.

What crosses into a sandbox​

Your mounted login stays inside the runner container. Agenta never uploads it to a Daytona sandbox. A run that requests Daytona with a self-managed credential is not supported. For the full trust model, see Sandbox isolation and security.