How to Use Multiple GitHub Accounts in Claude Code With Aident

If Claude Code needs to work across a personal GitHub account and a work GitHub account, connect both identities in Aident Vault, give each connection an unmistakable alias, and pass the intended alias on every GitHub Action. Verify the routed identity with an authenticated-user identity check before any repository write. Do not rely on whichever account happened to be connected last.

This solves a narrower problem than switching Claude subscriptions or terminal Git identities. Anthropic issue 27302 has hundreds of reactions and comments asking for multiple connector accounts because one global connector identity does not fit users who cross personal, work, client, or organization boundaries. GitHub CLI supports multiple authenticated accounts too, but gh auth switch changes the active account for a host. An agent workflow needs a selection that travels with the exact Action instead of hidden global state.

First separate the three account layers

People often say "switch GitHub accounts" while referring to different systems. Diagnose the layer before changing credentials.

Changing git config user.email does not change the account used by a GitHub API Action. Switching Claude profiles does not change GitHub repository access. This guide is only about the third row.

If you also need separate Claude subscription profiles, start with How to Use Work and Personal Claude Code Accounts Safely. Keep that boundary independent from GitHub routing.

1. Verify that multi-account routing is available

Start with the canonical installation prompt:

Follow https://aident.ai/SETUP.md

Then check authentication and current connections:

aident account auth status
aident vault vault --action status

Find the current GitHub integration rather than copying an internal identifier from an article:

aident capabilities search \
  --query "GitHub integration with multiple connected accounts" \
  --types '["integration"]' \
  --targetEnv staging

Copy the exact integration identifier returned by discovery into a local variable:

GITHUB_INTEGRATION="<exact GitHub integration identifier>"
aident capabilities connection account-list \
  --integrationId "$GITHUB_INTEGRATION"

Continue only when the live result exposes multiple-account controls such as canAddAccount: true. If it does not, do not manufacture an alias or reconnect the existing account under a different login. Keep one default account, use GitHub CLI's supported account switch for a human-controlled terminal job, or wait until the feature is available for your plan and integration.

2. Add the second account without replacing the first

Request an additional OAuth connection:

aident vault connect \
  --integrationId "$GITHUB_INTEGRATION" \
  --addAccount true

Open the returned connection URL yourself and sign in to the intended GitHub account. Do not paste a token, password, device code, or browser cookie into Claude Code. After OAuth completes, list the accounts again:

aident capabilities connection account-list \
  --integrationId "$GITHUB_INTEGRATION"

Expected result: both accounts are active and each has a distinct generated alias. If the second login replaced the first, the integration does not show two active accounts, or the provider identity is unclear, stop. Repeating the connection flow can make the ambiguity worse.

3. Rename aliases by purpose

Generated names such as Account 1 and Account 2 are easy to reverse. Rename them to the boundary that matters in review:

aident capabilities connection account-update \
  --integrationId "$GITHUB_INTEGRATION" \
  --accountAlias "<current alias for your personal account>" \
  --newAlias "Personal GitHub"

aident capabilities connection account-update \
  --integrationId "$GITHUB_INTEGRATION" \
  --accountAlias "<current alias for your work account>" \
  --newAlias "Work GitHub"

List the accounts after each rename. Use labels that describe ownership, not a provider email that might change. A client boundary can use Client Acme GitHub; a managed enterprise identity can use Work Enterprise GitHub.

Setting a default is optional. Defaults are convenient for one-account workflows, but a multi-account write should still name its alias explicitly. That makes the selected identity visible in the reviewed command.

4. Discover an identity check

Search for the current Action that returns the authenticated GitHub user:

aident capabilities search \
  --query "get the authenticated GitHub user" \
  --types '["action"]' \
  --targetEnv staging

Copy the exact Action name into a variable, then inspect its current contract:

IDENTITY_ACTION="<exact authenticated-user Action name>"

aident capabilities get \
  --name "$IDENTITY_ACTION" \
  --parts '["description","inputSchema","outputSchema"]'

Do not assume the schema is unchanged because an older run worked. Confirm that the Action needs no repository target, then run account-list again and confirm that it still includes the two aliases you reviewed. The provider operation retrieves profile information, but the live catalog may classify the Action conservatively as a write. Preserve the catalog's operation and risk metadata. If schema inspection returns no payload, stop instead of executing from the description alone.

5. Preflight once, execute once per alias

Validate the exact empty input before execution:

aident capabilities preflight \
  --name "$IDENTITY_ACTION" \
  --input '{}'

Continue only if the input is valid, the price is exact and inside your approved ceiling, and any catalog risk acknowledgement is understood and approved. Then run the same identity check once for each account:

aident capabilities execute \
  --name "$IDENTITY_ACTION" \
  --input '{}' \
  --accountAlias "Personal GitHub"

aident capabilities execute \
  --name "$IDENTITY_ACTION" \
  --input '{}' \
  --accountAlias "Work GitHub"

For each result, compare the provider login with the expected human account and compare the execution receipt's account alias with the alias you requested.

If either result is ambiguous, stop before touching a repository. Do not infer identity from a repository name, local directory, SSH remote, or the last successful call.

6. Pin the alias on every repository Action

After the identity test passes, discover and inspect the exact GitHub Action for the job. Keep the same alias on pre-write reads and the eventual write:

Target: owner/repository and exact issue or pull request
Account: Work GitHub
Effect: exact proposed mutation
Evidence: current target read through Work GitHub
Approval: explicit approval for that mutation
Verification: read the same target again through Work GitHub

The Action invocation must include:

--accountAlias "Work GitHub"

Account selection is not write approval. For comments, labels, pull-request state changes, workflow dispatches, or merges, inspect the current schema, preflight the exact payload, obtain any required acknowledgement or human approval, execute once, and read the target back. Never use account routing to bypass branch protection or repository policy.

For a broader comparison of GitHub connection routes, read GitHub MCP Server vs Aident Loadout for Codex. For the credential boundary behind this workflow, continue to How to Give AI Agents API Access Without Exposing Keys.

Why explicit aliases beat hidden switching

GitHub documents that gh auth switch changes the active account used for a host. That is useful for an interactive terminal, but it is mutable process state. The next command depends on a prior switch succeeding and remaining active.

An Action-level account alias makes the routing choice part of the call under review. The operator can see the target, effect, and identity together. The receipt can report which connected alias was used. This does not eliminate credential or provider mistakes, but it gives the workflow a concrete invariant to verify.

Use this reusable Claude Code prompt:

Follow https://aident.ai/SETUP.md

I have two authorized GitHub identities. Verify that the live GitHub integration
supports adding accounts before changing anything. Connect the second identity
through a user-opened OAuth URL without replacing the first. List both accounts
and help me rename them to Personal GitHub and Work GitHub. Discover the current
authenticated-user identity Action, inspect its schema, and preflight the exact
input. Execute it once per alias only after the preflight passes. Return the
requested alias, receipt alias, and provider login for each result. Stop on any
ambiguity. Do not create, edit, comment, label, close, merge, dispatch, delete,
or expose credentials

Set up Aident and verify two GitHub account routes.

Questions people ask

Can Claude Code use two GitHub accounts at once?

Claude Code can call an integration layer that has two authorized GitHub connections, but each Action should select one exact account alias. "At once" should not mean one ambiguous shared identity.

Is this the same as gh auth switch?

No. GitHub CLI switches the active account for a host. Aident's account alias is supplied with the individual Action, so the route is explicit in the reviewed invocation and execution receipt.

Should I make my work account the default?

Only if most of your safe reads use it. Still include the alias on multi-account writes. A default is a convenience, not evidence that the correct identity was used.

What if Vault does not show canAddAccount: true?

Stop. Do not reconnect the default account or invent an unsupported switch. Use one connected identity or a different reviewed route until the live integration and your plan expose multiple-account controls.

Conclusion

Keep Claude identity, Git commit identity, and GitHub integration identity separate. Connect the second GitHub account only when the live Vault contract supports it, replace generic account numbers with ownership-based aliases, and prove each route with an authenticated-user identity check. Then attach the intended alias to every repository Action and preserve normal approval and readback gates for writes.

Sources

• Anthropic Claude Code issue #27302: support multiple connector accounts

• GitHub Docs: use GitHub CLI across multiple accounts

• GitHub CLI manual: gh auth switch

• GitHub Docs: switching between accounts

• Anthropic Help Center: use the GitHub integration

• Aident Loadout setup

• Live Aident Loadout catalog, Vault status, command help, and connected GitHub account-routing contract inspected September 3, 2026. The live account list showed one current default GitHub alias and support for adding and managing accounts; no second account was connected or changed during research.

Refresh this guide when Aident changes Vault multi-account fields, account-update commands, Action routing or receipt fields; GitHub changes multi-account authentication; or Claude adds native per-connector account selection that changes the comparison.