Devsy
Developing in a Workspace

Reuse local credentials

Devsy makes some of your local credentials available inside the dev container, so you do not configure them in each workspace. It supports Git credentials, opt-in GitHub CLI authentication, Docker registry credentials, and GPG keys.

Only use with trusted repositories

Code that runs in the container, including lifecycle commands and features from devcontainer.json, can use these credentials. Do not enable them for repositories or devcontainer.json files you have not reviewed.

SSH agent forwarding never exposes your private key. It does let anything in the container request signatures, and so act as you against any service the key can access, for as long as the workspace runs.

Git

Devsy provides HTTPS credentials through a git credential helper. To turn off this credential injection in the default context:

devsy context set default -o SSH_INJECT_GIT_CREDENTIALS=false

SSH agent forwarding is separate and enabled by default (SSH_AGENT_FORWARDING=true). To disable it in the default context:

devsy context set default -o SSH_AGENT_FORWARDING=false

Disabling HTTPS credential injection does not disable SSH agent forwarding.

GitHub CLI

GitHub CLI credential forwarding is off by default. Enable it for a trusted context:

devsy context set <context> -o SSH_INJECT_GITHUB_CREDENTIALS=true

To disable it:

devsy context set <context> -o SSH_INJECT_GITHUB_CREDENTIALS=false

Desktop exposes the same option as GitHub CLI Credentials in the context's credential forwarding settings. This option is independent of Git HTTPS credentials, Docker credentials, SSH agent forwarding, and signing. A platform workspace's policy disabling Git credential forwarding also disables GitHub CLI forwarding.

Scope and prerequisites

Install and sign in to gh on your macOS, Linux, or Windows host. Install gh (or configure an executable version-manager shim) for the intended user in the Linux guest. Devsy does not install GitHub CLI or sign you in. A missing guest CLI leaves command -v gh unchanged; install it and reconnect to retry setup.

An enabled relay makes the host's stored active account on every configured GitHub host available to workspace code. This includes GitHub.com and each configured GitHub Enterprise host, with each token's existing API permissions. It is broader than access to the workspace repository: code can call GitHub APIs directly using those tokens. Only enable it for code you trust with that authority.

The host must have an active user registered in its GitHub CLI configuration, with a file token or an accessible keyring credential. Host GH_TOKEN, GITHUB_TOKEN, GH_ENTERPRISE_TOKEN, and GITHUB_ENTERPRISE_TOKEN values are excluded from account lookup; environment-only host authentication is not forwarded. Devsy does not call an API to invent an account identity. GitHub CLI itself selects the target host for commands, aliases, and extensions.

Guest authentication and saved changes

Nonempty explicit guest authentication environment variables and existing local file or keyring tokens take precedence, even if an API rejects them. Devsy does not retry an authentication failure with the host account. A registered guest account also prevents forwarding if its token cannot be retrieved: GitHub CLI cannot reliably distinguish an absent keyring entry from a locked or unavailable keyring. Repair or deliberately remove that guest registration to use forwarding.

Forwarded invocations use private temporary configuration. Forwarded values are stripped before user changes are written back. Deliberate local logins and keyring changes stay under GitHub CLI's control. Saving the exact forwarded token back to a file may remain treated as forwarding; disable forwarding before a login that must be independent of the host. Devsy serializes writeback from its wrappers and preserves a newer complete local identity when a conflict is detected, instead of combining accounts or resurrecting a logout.

An unwrapped gh process or another editor does not share Devsy's writeback lock. Changes detected before the final file replacement are preserved, including changes made while the journal checkpoint is saved. There is no atomic comparison-and-replacement guarantee against unrelated writers: an edit between the final comparison and replacement can still be overwritten. Avoid overlapping authentication changes through the wrapper and an unwrapped CLI or editor. Independent keyring changes are not rolled back through configuration writeback.

Normal completion scrubs forwarded credentials before attempting configuration writeback. An interrupted process can leave private temporary credentials until a later invocation recovers the session; cleanup failures are reported on stderr. This is not secure erasure. Host configuration and keyring accounts are not changed by guest commands.

Connections and troubleshooting

Close existing service connections and reconnect after changing the option. Restart a browser IDE when needed to replace its existing services connection. After opting in, an older browser tunnel must be restarted before Devsy can verify preparation and open it automatically. Changing the context option does not revoke tokens already obtained by running code.

The guest's shared credential port has one live services owner. SSH sessions carry their expected host and service identity; a mismatched or older service falls back to local authentication. Browser terminals and external SSH clients that do not carry this session environment use the first live services owner. Two hosts using the same guest user must end that first connection before changing the owner; the guest username alone does not identify a host. Do not rely on a second browser connection to change or revoke the first owner's authority.

If forwarding is unavailable, the wrapper runs the real CLI with local configuration. Check gh --version and gh auth status on both the host and guest, confirm the context option, and reconnect. Verify the guest user's PATH and noninteractive sudo access for wrapper setup. Locked keyrings, a missing session bus, old agents, failed setup, and occupied credential ports can prevent forwarding. DEVSY_LOG_LEVEL=debug gh ... explains the selected authentication source and sanitized failure category on stderr without changing GitHub CLI's stdout or exit status.

Docker

Devsy provides registry credentials through a Docker credential helper, so you can pull and push private images from the container. To turn it off for all workspaces:

devsy context set default -o SSH_INJECT_DOCKER_CREDENTIALS=false

GPG

Devsy can forward your GPG keys into the container over the SSH tunnel, so you can sign commits there. To turn it on for all workspaces:

devsy context set default -o GPG_AGENT_FORWARDING=true

Or for one workspace:

devsy workspace up --ssh-gpg-forwarding my-workspace

On this page