Authentication

jackin’ starts every agent container with the credentials it needs already in place — your Claude Code login, your Codex login, your Amp login, your OpenCode login, and your GitHub CLI login all flow into the container automatically, so the agent runs from the moment it starts and you never see a /login prompt or a gh auth login device-flow on first launch.

Every authentication axis jackin’ supports today follows the same pattern. The pages in this group cover the operator surface for each axis:

Agent Authentication
Claude Code, Codex, Amp, and OpenCode credentials forwarded into the agent container, with optional API-key or OAuth-token alternatives.

GitHub CLI Authentication
The host’s gh login forwarded so git push, gh commands, and the in-container GitHub MCP tools authenticate without prompts.

The shape every axis shares

Each axis has the same three knobs:

Three modes. sync is the default — forward the host login as-is. ignore opts out entirely. The remaining mode supplies a scoped credential through your operator env-vars layer instead of the broad host login (api_key or oauth_token for agents; token for gh).
Three configuration scopes. Global default, per-workspace override, and per-(workspace × role × agent) override. The most-specific scope wins.
Per-agent dimension where it makes sense. Agent forwarding has an agent dimension (Claude, Codex, Amp, and OpenCode are configured separately because their credentials and runtime expectations differ). GitHub CLI forwarding doesn’t — gh doesn’t care which agent is invoking it, so the same gh login is shared by every agent in the container.

The default everywhere is sync so a freshly installed jackin’ Just Works on the first launch. You opt into a tighter mode only when you want to bind a specific workspace or role to a scoped, least-privilege credential. The page for each axis explains how to do that and surfaces the launch-summary line that confirms which mode is active on every container start.

Why `sync` is the default

jackin’ is a security-first project — see Design Principles — but security and simplicity are not at odds here. Forwarding your existing host login is what most operators expect on first run, and the alternative (an empty container that prompts for credentials on every launch) trains operators to bypass safety because the safe default is too inconvenient. So sync is the out-of-the-box behaviour, and jackin’ provides explicit, well-documented paths to tighten the policy when a workspace or role calls for it.

This is the project’s default stance on every authentication axis it ever adds: ship something that works on first launch with sane defaults, and supply the tooling to lock it down where the operator needs to.

Managing auth — always through the operator console

The recommended way to view and edit any authentication setting — agent or GitHub CLI, global default or per-workspace or per-role — is the operator console:

jackin console

…then select your workspace and switch to the Auth tab. The same tab covers every authentication axis jackin’ supports. You pick the mode through a mode-picker; for modes that need a credential, the form opens the same 1Password / host-env / literal source picker used by the env-vars editor; the form refuses to save until the credential resolves.

You should not need to hand-edit any configuration file. Operators who prefer the CLI for global agent defaults can use jackin config auth …; GitHub CLI global defaults and all more-specific settings live in the console’s Auth tab today.

The per-axis pages in this group (Agent / GitHub CLI) describe the modes and the launch-summary line each axis prints, but the interface for managing those modes is uniform.

What jackin’ deliberately does not forward

jackin’ does not forward your host SSH keys into agent containers. SSH-key sync is the surface where things get genuinely dangerous — once an agent container holds a copy of your host’s SSH key, it can act as you against any system that key reaches, far beyond github.com. Even with the container’s own boundary, that’s a wider blast radius than the auth-forwarding axes this group covers.

For pushing to GitHub from inside the container, jackin’ uses HTTPS plus the forwarded gh login (see GitHub CLI Authentication) — that gives you the same git push workflow without the SSH-key surface.

Host machine is never modified

Authentication forwarding is one of the places where jackin’s repo-wide never mutate the host rule matters most. Forwarded credentials are read from your host but never written back; in-container token rotations stay inside the container; HTTPS rewrites and credential-helper wiring happen inside the container’s own git config, never in your ~/.gitconfig. See the design-principles page for the full rule and audit; this group’s per-axis pages call out the rule again only where it shapes a specific feature.