Problem

gh account selection is global which makes it difficult to work concurrently with agents. Ideally this should be made automatic & context-scoped (like git's includeIf). For users with multiple accounts logged in with different access this is problematic when those accounts have different access restrictions that are not host-based.

git already solves the "multiple identities on one machine" problem automatically via path-based config (or pseudo-host based config) includes and does not require manual switching or wrapper scripts:

# ~/.gitconfig
[includeIf "gitdir:~/personal/"]
  path = ~/.gitconfig-personal
[includeIf "gitdir:~/work/"]
  path = ~/.gitconfig-work

alternatively pseudo-host based looks something like

[url "[email protected]:acme/"]
  insteadOf = [email protected]:acme/
  insteadOf = https://github.com/acme/
  insteadOf = ssh://[email protected]/acme/

# with the following in ssh_config

# your default
Host github.com
  IdentitiesOnly yes
  IdentifyFile ...

# acme org
Host acme.github.com
  HostName github.com
  IdentitiesOnly yes
  IdentifyFile ...

Both of those methods use the right identity transparently and per-repo without mutating global state.

The gh commands silently use whatever account happens to be globally active. While gh commands are host aware this is completely unsolved when both accounts are on the same host (an EMU + a public github.com identity), where hostname can't disambiguate the user.

Ideal end state

gh should resolve the acting account automatically from context the same way git does instead of requiring a global switch. Ideally it could even reuse/mirror the resolution git already performs (e.g. infer based on account authorization and the git organization/repo access, with some user-defined default in ambiguous cases).

An example (fake accounts)

Identities (both on github.com):

Directory layout:

~/personal/     → work as octocat
~/work/         → work as octocat_acme (EMU)

git today (works automatically):

# ~/.gitconfig
[includeIf "gitdir:~/personal/"]
  path = ~/.gitconfig-personal      # user.email = [email protected]
[includeIf "gitdir:~/work/"]
  path = ~/.gitconfig-work          # user.email = [email protected]

gh today (broken):

$ cd ~/work/acme-corp/billing-api
$ gh pr create ...
# ✗ runs as whatever `gh auth switch` last set globally.
#   If that was `octocat`, the PR/comment is authored by the WRONG identity —
#   and an EMU repo may reject or misattribute it.

gh desired — automatic, context-scoped resolution.** Illustrative shape (any of these, not prescriptive):

# ~/.config/gh/config.yml  (illustrative)
account_rules:
  - if_gitdir: "~/personal/"
    account: [email protected]
  - if_gitdir: "~/work/"
    account: [email protected]
  # or resolve by repo owner, independent of directory:
  - if_owner: ["acme-corp", "acme-labs"]
    account: [email protected]
  - if_owner: ["octocat"]
    account: [email protected]

$ cd ~/work/acme-corp/billing-api
$ gh pr create ...
# ✓ automatically acts as octocat_acme — no global switch, no wrapper script,
#   no mutation of state that affects other shells or agents.

$ cd ~/personal/dotfiles
$ gh pr comment 12 --body "lgtm"
# ✓ automatically acts as octocat.

Automated agents managing PRs/comments across both identities can't safely gh auth switch as it's a global racy mutation and there's no per-invocation --acount ... primitive for same-host accounts. Context-based resolution means an agent (or human) just cds into the repo and every gh call is already the right identity, matching the git behavior they already trust. As an escape hatch, an explicit override (gh --account <user>@<host> / GH_ACCOUNT) covers cases outside any repo.

Prior art / references

• Original request: cli/cli#326 (open since Feb 2020); path-based (includeIf-style) switching requested repeatedly in-thread
• Root-cause analysis: cli/cli#12885
• Owner→user mapping PR (auto-closed): cli/cli#13130
• Git Config Setting: #12459, #13529
• Related: cli/cli#12145, #9111, #11938