Credential resolution — env → OS keyring → dotfile. Never cleartext.
After installing credential-brokers, every credentialed skill in your toolkit resolves its token in-process — environment variable, OS keyring, or a local dotfile — without the value ever reaching the model. You set up a credential once; every subsequent session that needs it resolves it automatically.
credential-setup1 gateWalks through establishing a credential for a service — API key, personal access token, or SSO cookie — and stores it via the configured resolution chain.
You decide to install a credentialed pack — figma, atlassian, or another service that requires an API key or personal access token. The agent walks you through identifying what credential type the service requires and which resolution path to use.
You: Decide where the credential will live — environment variable, OS keyring, or dotfile — based on your environment and security preferences. Read the credential-setup output to confirm the resolution path makes sense. For most developer workstations, the OS keyring is the right choice: it persists across terminal sessions and is encrypted at rest. For CI environments, an environment variable is the right choice.
The agent runs credential-setup, prompts for the token value (which is never logged), and stores it via the configured resolution chain. It then runs a test invocation to confirm the credential resolves correctly before ending the session.
You: Provide the token value when prompted — this is the one moment the credential passes through your clipboard or input. Verify the test invocation succeeded. If it fails, work through the resolution chain with the agent: is the environment variable exported in the current shell? Is the keyring unlocked? Is the dotfile in the expected location and readable?
After setup, the credential resolves automatically in every subsequent session that needs it. No repeat entry. The token value is stored in the configured location and never passes through the model again.
You: Confirm that the first real invocation of the credentialed skill works end-to-end. The most common post-setup failure is a scope mismatch — the token was set up correctly but lacks the permissions the skill needs. If a skill returns an auth error after a successful setup, the first check is always: does this token have the right scope for this operation?
For each gate, everything you need to make a confident decision.
A credential stored in the right resolver for your environment, with the correct scope for every skill that will use it — confirmed by a test invocation before you leave the setup session.
A credential stored in an environment variable that only exists in the current shell — it works now, silently fails in a new terminal or CI. Or a token set up for read access when the skills you're installing need write access.
A credential that works in setup but fails at runtime is the most common source of confusing mid-session errors. Credentialed skills report auth failures with opaque messages — the setup gate is the cheap place to discover the mismatch.
agentbundle install --pack credential-brokers --scope user