Contexts

Every platform credential lives in one of two contexts: work or personal. That gives two independent credential sets per platform — an employer's GitHub token and a personal one never mix, and every action runs against exactly one of them.

One credential for both

omni-cli github login --context both

For a single account on a platform, logging in with --context both stores a single shared credential that both contexts resolve to. status marks it (shared), and logging out clears it for both. Note that both is a login/logout idiom only — an action never accepts --context both (that's a usage error, exit 2); it always runs as work or personal.

How the CLI picks a context

When an action runs, the context is resolved through this chain — first match wins:

1. An explicit --context work|personal flag.
2. The OMNI_CONTEXT environment variable.
3. A directory binding — the longest bound ancestor of the current directory (see below).
4. The global default set with omni-cli context use.
5. Inference: if exactly one of the two contexts has any credential, it's used. A shared credential counts as both, so it never infers.

If none of these apply, the command fails with exit code 3 (context_unresolved) and says how to fix it.

Directory bindings

omni-cli context bind . --context work     # bind a directory (default: cwd)
omni-cli context list                      # show all bindings
omni-cli context unbind .                  # remove a binding

A binding maps a directory to a context: any command run in that directory — or anywhere below it — resolves to the bound context. When several bindings match, the deepest (longest) one wins, so ~/code can be bound to work and ~/code/side-project to personal.

Default context

omni-cli context use work          # set the global default
omni-cli context use --clear       # unset it

The default applies when no flag, env var, or binding does. After the first platform login the CLI suggests pinning one — it future-proofs resolution against a later second login making things ambiguous.

Checking what resolved

omni-cli context status

Shows the resolved context, which step of the chain won (flag, env, binding, default, or inferred), and every in-definition platform's login state grouped by context — the resolved context is marked (active). During normal runs the CLI stays quiet about context, with one exception: a mutating action on an inferred context prints the context first — the one case where the write wasn't explicitly scoped.

Logins resolve differently

login and logout never use the env var, bindings, or inference — they take an explicit --context or ask interactively. Storing a credential in the wrong context is worse than one extra prompt.

Agents should pass --context explicitly on every action. The resolution chain is built for humans at a shell; an explicit flag makes an agent's invocations deterministic regardless of directory, env, or login state.

Read this page as markdown — the copy your coding agent fetches.