# Authentication (https://jackin.tailrocks.com/guides/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 `Kimi` login, your `OpenCode` login, your `Grok` 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](/guides/authentication/agents/)**\
`Claude Code`, `Codex`, `Amp`, `Kimi`, `OpenCode`, and `Grok` credentials forwarded into the agent container, with optional API-key alternatives (plus OAuth token for Claude Code).

**[GitHub CLI Authentication](/guides/authentication/github-cli/)**\
The host's `gh` login forwarded so `git push`, `gh` commands, and the in-container GitHub MCP tools authenticate without prompts.

**[Z.AI (GLM Coding Plan)](/guides/authentication/zai/)**\
Configure `ZAI_API_KEY` to unlock Z.AI as a selectable provider for Claude Code sessions — an Anthropic-compatible GLM endpoint that runs alongside Anthropic tabs in the same container.

**[MiniMax (Token Plan)](/guides/authentication/minimax/)**\
Configure `MINIMAX_API_KEY` to unlock MiniMax as a selectable provider for Claude Code sessions — MiniMax's Anthropic-compatible endpoint backed by MiniMax-M3.

**[Kimi](/guides/authentication/kimi/)**\
Configure `KIMI_CODE_API_KEY` to unlock Kimi as a selectable provider for Claude Code sessions — Kimi's Anthropic-compatible coding endpoint backed by `kimi-for-coding`.

## The shape every axis shares [#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`, `Kimi`, 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 [#why-sync-is-the-default]

jackin❯ is a security-first project — see [Design Principles](/getting-started/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 [#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:

```bash
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 [#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](/guides/authentication/github-cli/)) — that gives you the same `git push` workflow without the SSH-key surface.

## Host machine is never modified [#host-machine-is-never-modified]

Authentication forwarding is one of the places where jackin❯ repo-wide *[never mutate the host](/getting-started/design-principles/#never-mutate-the-host-machine-silently)* 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.

## See also [#see-also]

* [Environment Variables](/guides/environment-variables/) — how the operator env-vars model supplies credentials for the non-`sync` modes.
* [Security Model](/guides/security-model/) — the broader container boundary and what authentication forwarding does (and does not) imply.