# Amp (https://tenki.cloud/docs/sandbox/amp) > For the complete documentation index, see [llms.txt](https://tenki.cloud/llms.txt) Start from Tenki's pre-built Amp image and run Sourcegraph's coding agent headlessly. Run Sourcegraph's Amp coding agent non-interactively in a disposable Tenki sandbox. Tenki's public `tenki/amp:stable` image starts from the standard [`sandbox` base image](https://tenki.cloud/docs/sandbox/base-image.md) and adds Sourcegraph's Amp coding agent (the `amp` command) plus the `amp-smoke` command for the API-key path. No credential is baked into the image. Amp authenticates two ways and both work in a sandbox: an `AMP_API_KEY` from your ampcode.com account passed per session, or a device-code login with `amp login`. The key is the better default here, since nothing has to be approved by hand and a session can start and finish unattended. Either way you authenticate an Amp account billed on usage, not a provider key (such as an Anthropic or OpenAI key) that you already hold, so every run spends Amp credits. Sandbox usage is programmatic, so you drive Amp with its execute mode, `amp -x`, which runs a single task and exits. ## Amp: Sourcegraph's coding agent in your sandbox Amp is Sourcegraph's agentic coding agent. It reads and edits a working tree, runs commands, and calls tools to complete a task from a prompt. Its execute mode, `amp -x`, runs one prompt non-interactively and exits, which is what suits CI and programmatic use inside a sandbox. Every run is organized as a thread; on this image those threads are stored on your Amp account, which is covered under [Threads](#threads) below. ## Start a session with an API key Export an Amp API key (format `sgamp_...`, from your ampcode.com account settings) locally, then pass it only to the session. Amp reads it straight from the session environment, so it needs no login step or on-disk auth file: ```bash export AMP_API_KEY= tenki sandbox create \ --image tenki/amp:stable \ --env "AMP_API_KEY=$AMP_API_KEY" \ --name amp-demo ``` Pass the key only through `--env` when you create the session. Never put it in a template, image, or source file, where it would reach every session built from them. Snapshots taken from this session also contain the key. Run the built-in connectivity check: ```bash tenki sandbox exec --session amp-demo -- amp-smoke ``` `amp-smoke` runs one headless `amp -x` prompt with your `AMP_API_KEY` and checks that the model replies with an expected token. A successful result looks like: ```text pong ``` `amp-smoke` exits `2` when `AMP_API_KEY` is unset and `1` when the headless run fails, including when it times out. Terminate the Tenki session when you finish: ```bash tenki sandbox terminate amp-demo ``` ## Start a session with a device-code login Use this path to sign in with your Amp account instead of passing an API key. Create the session with no key: ```bash tenki sandbox create --image tenki/amp:stable --name amp-demo ``` Open a shell over SSH and log in: ```bash tenki sandbox ssh amp-demo amp login ``` `amp login` prints a device URL on `ampcode.com` and a code. Open that URL on your own machine, confirm the code matches, and Amp prints `Logged in as `. The login is stored in `~/.local/share/amp` and survives pausing and resuming the session. Exit SSH; `amp -x` then runs with no `AMP_API_KEY` set. Run `amp logout` before you terminate the session if you do not want the login left active on your account. If a session has both, `AMP_API_KEY` takes precedence over the stored login, so an invalid key fails the run even when a valid login is present. ## Run a headless task Drive Amp programmatically with the `-x` flag, which runs a single prompt and exits. For anything beyond `-x`, run `amp --help` inside the session or see [Amp's documentation](https://ampcode.com/manual). ```bash # One-shot task against the working directory inside the session tenki sandbox exec --session amp-demo -- amp -x "summarize this repo's build setup" # Against your own project: clone it into the session first, then run amp inside it tenki sandbox exec --session amp-demo -- \ bash -lc "git clone https://github.com/your-org/your-repo /home/tenki/work && cd /home/tenki/work && amp -x 'list the top-level modules and how they build'" ``` Amp can also route threads through your own model provider keys or subscriptions (BYOK) with `amp config model-providers`. Those connections are stored on your Amp account and change which model serves a thread, not how Amp authenticates: an Amp login or `AMP_API_KEY` is still required. ## Permissions Amp has a permission system, but this image does not turn it on. The shipped settings set only `amp.updates.mode`, and Amp loads its permission gate only when the settings opt in, through an `amp.permissions` rule, an explicit `amp.dangerouslyAllowAll`, or `amp.guardedFiles.allowlist`. With none of those set, an `amp -x` run executes its tool calls, including shell commands, without prompting and without denying. There is no interactive prompt for an unattended run to stall on. That posture is deliberate: the Tenki sandbox is the whole safety boundary. Amp runs as the unprivileged `tenki` user (uid 1000), which has passwordless `sudo`, so it can do anything that user can, which is effectively everything in the guest. What it cannot reach is the host, other tenants' sessions, and the Tenki control plane, and it reaches the network only through the sandbox's egress. The VM is disposable. Note that `amp.dangerouslyAllowAll` is a setting in `settings.json`, not a `--dangerously-allow-all` command-line flag, in the current Amp CLI. Because the image already runs without the gate, turning that setting on changes nothing. The setting that changes behavior is `amp.dangerouslyAllowAll: false`, which turns the gate on. If you want Amp's own gate for a particular run, edit `~/.config/amp/settings.json` and set `amp.dangerouslyAllowAll: false` or add an `amp.permissions` rule; `amp -x` then blocks an un-allowlisted command and reports it as denied rather than running it. ## Threads Unlike the other pre-built images, Amp is not self-contained. Every `amp` run creates a thread on ampcode.com that your Amp account can open from its other clients. What is sent is the prompt, the conversation history, tool results, and the context Amp collects for the task; Amp states it does not clone or index your whole codebase. Conversation state leaves the sandbox. Threads are private by default, and `--visibility private|unlisted|workspace|group` scopes who can access one. `amp -x` archives its thread when it finishes unless you pass `--no-archive-after-execute`. Visibility and archiving control access; neither stops the thread from being stored. Terminating the session erases the local Amp state in `~/.config/amp` and `~/.local/share/amp`, but the server-side thread survives until you delete it from your Amp account. The usual sandbox guarantee that nothing carries between sessions does not hold for this image, so treat anything you send to Amp as leaving the guest. ## Pin an exact build Amp has no stable release channel: its versions are rolling build ids (`0.0.-g`) that Amp ships continuously, and `tenki/amp:stable` is the Tenki image tag, not an Amp channel. The image pins one Amp build and disables Amp's in-session updater, so a session stays on the build the image was tested against. The pin covers the `amp` binary only: at startup Amp downloads its agent-mode and model definitions from ampcode.com, so which model serves a mode can change without a new image. When a workload has to stay on the exact image build too, resolve the tag once and launch the snapshot reference it returns: ```bash tenki sandbox registry resolve tenki/amp:stable # image_id : # snapshot_id : tenki sandbox create --image tenki/amp@ ``` A snapshot reference never moves, so it keeps launching that build after `stable` advances.