Let Chainguard Workspaces sessions act on GitHub as you
Connect your GitHub account so that the Chainguard Workspaces sessions you create act on GitHub as you through the …
For the complete documentation index, see llms.txt.
This guide walks you through signing up for Chainguard Workspaces, opening a session on one of your repositories, detaching from the session, and returning to it. It takes about 15 minutes.
Note: Chainguard Workspaces is in beta. Available to organizations that turn it on with
chainctl develop init, which comes with a free monthly allowance, or that arrange access with their Chainguard account team.
Before you begin, make sure you have the following:
Workspaces uses the chainctl develop command. If you don’t have chainctl yet, follow the chainctl installation guide.
This guide needs chainctl 0.2.380 or later. Earlier releases can’t sign you up as this guide describes or run Claude Code in a session. If you already have chainctl, update it to the latest release, because Workspaces changes often during the beta:
sudo chainctl updateIf you installed chainctl with Homebrew, run brew upgrade chainctl instead. Refer to Updating chainctl for details.
By default, sessions fetch and push your repository through the Chainguard App, a GitHub App that also backs Chainguard Checks and Guardener. The sign-up in the next step links your Chainguard organization to a GitHub account.
The chainctl develop init command signs you in, creates a free Chainguard Starter organization if you don’t have one, and turns on Chainguard Checks and Chainguard Workspaces with a free monthly allowance that resets on the first day of each month (UTC). Run it in an interactive terminal, because it opens your browser and asks questions as it goes:
chainctl develop initTo create an organization, sign in with an email address and password or with Google. Other sign-in methods, such as GitHub, can’t create one.
The command does the following:
--parent.Enter for your own GitHub user, or enter the name of a GitHub organization you own, such as acme, not a URL. It then opens your browser so you can authorize the link. If the Chainguard App isn’t installed on the account, it offers to open the page that installs it, then authorizes and links again.chainctl develop github login, as described in Let sessions act on GitHub as you.A GitHub account can be linked to only one Chainguard organization at a time. When you authorize the link, GitHub might ask you to authorize single sign-on for your GitHub organizations. Linking your own GitHub user doesn’t need it, so you can select Continue. To link an organization that requires SAML single sign-on, authorize single sign-on for that organization.
You can answer some of the questions ahead of time with flags. For example, to link the acme GitHub organization instead of your own GitHub user:
chainctl develop init --github-org acmeFor every flag, refer to the chainctl develop init reference.
If your company already has a Chainguard organization, chainctl develop init can’t create another one for your email domain, so ask an owner of that organization to add you, as described in Give teammates access. If the command stops with an error, refer to chainctl develop init fails.
If your organization already has Workspaces through your Chainguard account team, someone with the owner role must accept the terms before anyone can open sessions in it, as described in chainctl develop accept-terms.
Change to your repository’s directory, then run chainctl develop. Replace $REPO_DIR with the path to your local clone, and $ORGANIZATION with the name of your Chainguard organization:
cd $REPO_DIR
chainctl develop --parent $ORGANIZATIONIf you belong to only one Chainguard organization, you can omit --parent.
The first time you run the command in a directory, chainctl creates a session, syncs your directory into it, and attaches your terminal to a shell in the session. The session gets a name made of the repository name and two generated words, such as app/quiet-harbor, and a short ID, such as 3f9a2c1e. If your repository has neither a .chainguard/develop.yaml file nor a .chainguard/ci.yaml file, the session opens on the default environment.
While you’re attached, chainctl keeps a status row at the bottom of your terminal. The row lists the session’s terminals and shows messages from chainctl. To open more terminals in the session, refer to Use several terminals in a session. The first time you attach to a session from your laptop, chainctl also prints a short guide to the status row and the session menu’s keys above the shell’s prompt.
Your shell runs as root in /work, which holds your repository. Try a few commands to look around:
git status
cat /etc/chainguard/session.yamlThe git status output matches your laptop’s checkout at the moment you opened the session, including uncommitted changes. The /etc/chainguard/session.yaml file records the session’s ID, repository, and commit, and the environment it was built from.
From here, you can work as you would on your laptop. For example:
claude to start Claude Code. It uses your laptop’s Claude Code login. Refer to Use Claude Code in a session.run-ci to run your repository’s checks against the working tree, if your .chainguard/ci.yaml defines checks.git push. Your laptop’s git user.name and user.email are already set in the session, and the Chainguard App, or Chainguard Develop if you connected your GitHub account, adds the credential for the push.Commits you make in a session aren’t signed, because the session gets your git user.name and user.email but not your signing key or settings. If a branch requires signed commits, GitHub rejects your push to it. To get your work onto that branch, refer to The branch requires signed commits.
To detach, press Ctrl+] to open the session menu, then press Enter or d to choose Detach — let it park. Your terminal returns to your laptop’s shell. The session keeps running for about 10 minutes, then parks to a snapshot and stops using compute.
To return, run chainctl develop again from the same directory:
chainctl develop --parent $ORGANIZATIONBecause the directory has exactly one session, chainctl reattaches to it, resuming it first if it parked. Your files, running processes, and shell are as you left them.
Your directory syncs into the session only the first time you attach. Changes you make on your laptop after that don’t reach the session, and changes in the session don’t reach your laptop. To move work between them, push from one and pull on the other.
A parked session expires 5 days after it parks, and until then it counts toward your session limit. With the free monthly allowance, you can have one session at a time, so delete it when you’re done. First, list your sessions to find its name:
chainctl develop list --parent $ORGANIZATIONThen delete the session by name. This example deletes app/quiet-harbor:
chainctl develop delete app/quiet-harbor --parent $ORGANIZATIONThe delete command asks you to confirm, then destroys the session’s VM and its snapshot. Anything you didn’t push is gone.
Each teammate opens and manages their own sessions, which count toward your organization’s limits. To open sessions, a teammate needs the owner or limited_owner role, or the sandbox.user role together with viewer. Refer to Roles.
In a Starter organization, the steps differ, as described in Add a teammate to a Starter organization. If you have the owner role in your organization, invite your teammate and grant them the sandbox.user role as follows:
Create an invite for your teammate with the viewer role. Your teammate needs it as well as sandbox.user, because sandbox.user alone doesn’t let chainctl develop find your organization. Replace $EMAIL with your teammate’s email address:
chainctl iam invite create $ORGANIZATION --role viewer --email $EMAILSend your teammate the invite code that the command prints. Your teammate accepts the invite by logging in with it, replacing $INVITE_CODE with the code:
chainctl auth login --invite-code $INVITE_CODEAfter your teammate accepts, list your organization’s role-bindings. The output shows each member’s identity ID next to their email address:
chainctl iam role-bindings list --parent $ORGANIZATIONGrant your teammate the sandbox.user role, replacing $IDENTITY_ID with their identity ID:
chainctl iam role-bindings create --identity $IDENTITY_ID --role sandbox.user --parent $ORGANIZATIONYour teammate can then install chainctl, as described in Step 1, and open a session, as described in Step 4. For more about roles, refer to Overview of roles and role-bindings.
If you created your organization with chainctl develop init, it’s a Starter organization, and you have the limited_owner role rather than owner. You can’t create role-bindings for other users, so you can’t grant the sandbox.user role. An invite can give only a role whose permissions you also have, and of those roles, only limited_owner can open sessions.
To let your teammate open sessions, run step 1 of Add a teammate with --role limited_owner instead of --role viewer, replacing $EMAIL with your teammate’s email address:
chainctl iam invite create $ORGANIZATION --role limited_owner --email $EMAILThe limited_owner role also lets its holder manage your organization’s billing and invite or remove members. Your teammate accepts the invite as described in step 2 of Add a teammate.
Invites in a Starter organization have the following limits:
--email, and the address must be in your organization’s domain or one of its subdomains.A coworker whose email address is in your organization’s domain can also ask to join by running chainctl starter request-access, which emails you the request.
Last updated: 2026-10-13 00:00