Skip to content

feat(exec): let a provider name stand in for its active account - #11

Merged
jiunbae merged 1 commit into
mainfrom
feat/exec-provider-target
Sep 22, 2026
Merged

jiunbae merged 1 commit into
mainfrom
feat/exec-provider-target

Conversation

@jiunbae

@jiunbae jiunbae commented Sep 22, 2026

Copy link
Copy Markdown
Member

Why

aas exec codex answered Account not found: codex, for a name the rest of the CLI already understands. switch, status and active all take a provider and resolve it to whatever that provider has active — exec and proxy were the two that insisted on an account name.

$ aas e codex          # before: Account not found: codex
$ aas e codex          # after:  runs e-ed@codex
$ aas codex            # the bare form follows too
$ aas e grok           # No active account for provider 'grok'. Name an account, or run: aas switch <account>
$ aas e nope           # Account not found: nope

Design

AccountStore::resolve_run_target reads a name as an account first, then as a provider standing in for that provider's active account.

  • Account names win. An account called codex keeps addressing that account rather than becoming unreachable — covered by an_account_named_after_a_provider_wins_over_the_active_account.
  • No active account resolves to nothing, rather than picking one. exec turns that into a message naming which of the two lookups failed.
  • Aliases resolve like the provider they name (claude-code → claude), since it goes through normalize_provider.
  • The bare aas <provider> form follows for free: rewrite_default_exec_args decides what counts as a run target through the same lookup.

Provenance

Written by hand on one of our hosts against v0.1.11 and never committed — found while auditing uncommitted work across the fleet, preserved at wip/jiun-mini-exec-provider-target, and rebased here (18 commits of drift; one conflict in exec.rs, where today's caller_system_home landed in the same spot — both kept).

Verification

  • All four branches exercised against the real CLI, as above.
  • Five tests: two in store.rs for the resolution order and the account-name-wins case, two in main.rs for the bare form with and without an active account, plus the existing rewrite tests.
  • 197 tests pass; clippy/fmt clean.

🤖 Generated with Claude Code

@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits. You can see your limits in the Codex usage dashboard.

`aas exec codex` answered "Account not found: codex" — a name every
other command already understands. `switch`, `status` and `active` all
take a provider and resolve it to whatever that provider has active;
`exec` and `proxy` were the two that insisted on an account name.

`resolve_run_target` gives them the same reading: a stored account name
first, then a provider name standing in for that provider's active
account. Account names win, so an account called `codex` keeps
addressing that account rather than becoming unreachable, and a provider
with no active account resolves to nothing rather than picking one —
`exec` then says which of the two lookups failed:

  No active account for provider 'grok'. Name an account, or run: aas switch <account>

The bare `aas <provider>` form follows, since `rewrite_default_exec_args`
decides what counts as a run target through the same lookup.

Written by hand on jiun-mini against v0.1.11 and left uncommitted;
preserved at `wip/jiun-mini-exec-provider-target` and rebased here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jiunbae
jiunbae force-pushed the feat/exec-provider-target branch from 46f0577 to c318048 Compare September 22, 2026 11:58
@jiunbae
jiunbae merged commit a312f4e into main Sep 22, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant