Git, SSH and custom credentials

You add a git token or an ssh key to Isolation on the Credentials page, and they are personal: nobody else in the organization can see, use or list them. Git is how a session reaches your repositories, SSH is how you reach a session, and custom is anything else the sandbox must call but must never hold.

Git

A git credential is one of two things. The linked GitHub account is one click: Connect GitHub asks for read:user, user:email and repo, and the connection itself is the credential, a row for github.com labeled with your name or GitHub login, covering every repository the account can reach. A token per host is for everything else: gitlab.com, git.acme.dev, a second GitHub account. Paste the host and the token; every token goes out as Basic x-access-token:<token>, which is what git hosts expect.

Several credentials may share a host, a personal and a work login say, and a repository names the one it uses: the picker in repos, views and environments offers a repository once per credential that can reach it.

Via Isolation or direct to host

Git is the only kind with a delivery choice, made once, when you add it:

Via Isolation, the sandbox holds a scoped token bound to Isolation's /git route, which swaps it for the real token upstream. Direct means the real token sits in the sidecar's memory on your server and requests go straight to the host, with no Isolation in the path. Either way the token never enters the sandbox and the remote never carries it. Delivery is fixed at creation; to change it, add a new credential. A repository cloned over ssh uses a deploy key on the repository instead, as how secrets travel explains.

Who your commits are from is a separate setting. git_identity_get shows it and git_identity_set picks one of three modes: your account's name and email, GitHub's no-reply address (keeps your email out of every commit, needs GitHub connected), or a name and email you type. In chat it is /git-identity.

SSH

An ssh credential is a public key, ssh-ed25519, ssh-rsa, ecdsa or a security-key variant, and its label names the machine it belongs to. At launch every key you hold is written into the session's authorized_keys at 0600 in a 0700 directory, with the label as the key's comment. It is how you get into a session from outside:

ssh <routeId>@ssh.isolation.cc            # a shell, tmux attached
scp <routeId>@ssh.isolation.cc:/work/out.log .
ssh -L 3000:localhost:3000 <routeId>@ssh.isolation.cc

The route id comes from a view's Open externally menu, or from /ssh in chat. The same key is what VS Code, Cursor, Windsurf and Zed use to open the session over ssh; work from your IDE covers those deep links. Because a public key is public, it is the one credential a chat may add: /add-key <your public key> in Slack or Teams works, while every other kind is refused there.

Custom

A custom credential is a host, a header shape and a value: Bearer, Basic, or an API key in a header you name (x-api-key, say). It is for a host the code inside must call, a payment API in test mode or an internal service, without ever holding the token. Delivery is direct by construction: there is no gateway to swap through, because the app inside calls the real host. The egress sidecar binds the whole host, so every request the sandbox makes to it leaves with the header added, whatever the path.

Inside the session nothing is configured. Code calls https://api.example.com with no key at all and the call arrives authenticated. One custom credential per host; to rotate it, edit the value in place. Variables your code reads by name are a different mechanism: environments, variables and secret files.

Where each one is used

credentials_list shows labels, hosts, kinds and delivery on every door, never a value. credential_delete removes one; a repository pointing at it falls back to having none until you pick another. The GitHub connection is also a connected app, see GitHub.