Auth credentials provisioned with incomplete scopes

[sentry-junior]

When Junior provisions GitHub auth credentials during a workflow, the initial OAuth grant may not include all scopes that later operations require. When a subsequent operation needs a scope that wasn't requested upfront, Junior fails silently or gets stuck — it doesn't know how to re-prompt for the missing scopes.

• Initial auth flow requests a limited set of scopes sufficient for the first operation
• Later operations in the same or future sessions may require additional scopes (e.g. repo write after initially only needing read)
• No mechanism to detect missing scopes and trigger a re-authorization flow
• Junior doesn't surface a clear error or remediation path to the user

Expected behavior:

• Auth should request the full set of scopes needed across all supported operations upfront, or
• When a missing-scope error is detected, Junior should prompt the user to re-authorize with the required scopes

Action taken on behalf of David Cramer.

[dcramer]

Proposed plan: plugin-declared command proxies

After digging into this, the GitHub case is not really OAuth scope escalation. GitHub is using GitHub App installation auth. The failure mode is that Junior currently mints a GitHub token from the full plugin manifest permission set at skill-load time. When the manifest grows, for example Actions support, an installation that has not approved the new permission can fail even for unrelated issue/PR work.

The goal should be deterministic credential activation without requiring:

• model-visible jr-rpc issue-credential
• hardcoded GitHub behavior in core
• skill frontmatter that generic skills cannot know about
• parsing arbitrary bash command strings as the auth authority

Mechanism

Add a plugin-owned command-proxies manifest surface:

command-proxies:
  - command: gh
    provider: github
  - command: git
    provider: github

For another provider:

command-proxies:
  - command: sentry
    provider: sentry

Core only implements the generic proxy system. Plugins declare which command names should activate which provider.

Runtime flow

1. During sandbox setup, Junior writes generic wrappers into /vercel/sandbox/.junior/bin for each declared proxy command.
2. Sandbox bash already prepends /vercel/sandbox/.junior/bin to PATH, so normal calls like gh issue view ... hit the wrapper first.
3. The wrapper calls a host activation bridge with provider, command name, argv, sandbox id, command id, and a short-lived turn/command-scoped bridge token.
4. The host validates the bridge token, asks the provider broker for a lease, and updates the active sandbox command network policy/header transforms.
5. The wrapper execs the real command by resolving the next binary outside .junior/bin.
6. The outer bash executor restores the original network policy when the command finishes, including failure/timeout paths.

The wrapper never receives the real token. Secrets stay host-side and are still delivered through header transforms plus sandbox placeholder env vars.

GitHub broker change

For GitHub App credentials, stop converting the full plugin manifest capability list into the installation token request body.

Instead, mint from the installation grant that GitHub has actually approved. The practical implementation can either omit the permissions body when creating the installation token, or fetch the installation grant and request only the granted intersection.

That means adding github.actions.write to Junior no longer breaks issue-only workflows on installations that have not approved Actions yet.

If a workflow later needs an ungranted permission, return a typed GitHub App permission error:

GitHub App installation is missing actions:write; an org/repo admin must approve the updated app permission.

Do not start OAuth for GitHub App permission failures.

OAuth provider behavior

For OAuth-backed providers, the proxy bridge should use the existing broker behavior:

• If the requester has a valid stored token satisfying the provider full declared scope set, activate it.
• If the token is missing, expired, or missing required scope, start the private OAuth flow with the full provider scope set, checkpoint the turn, and resume after callback.

jr-rpc

Keep jr-rpc for config only. Do not reintroduce jr-rpc issue-credential as a required model-visible step. It is too easy for the agent to skip.

Role of just-bash

Use just-bash command collection only as an optimization or early diagnostic. It can pre-activate credentials for simple scripts, but the wrapper is the deterministic mechanism because it also catches scripts, subshells, and generated commands that eventually invoke the proxied binary.

Scope and limitations

This solves normal provider CLI usage from any skill, including skills outside the provider plugin.

It does not catch:

• explicit /usr/bin/gh
• direct curl https://api.github.com
• custom binaries that call GitHub without using gh or git

Those remain future work for a fully request-aware network proxy.

Rollout

1. Hotfix GitHub token minting so manifest permission growth does not brick existing installations.
2. Add command-proxies manifest schema, types, validation, and docs.
3. Generate/install command wrappers in .junior/bin.
4. Add the host activation bridge and command-scoped network-policy lifecycle.
5. Wire the bridge to provider brokers and typed permission/auth errors.
6. Migrate GitHub plugin to declare gh and git; consider Sentry sentry next.
7. Add integration coverage.

Required tests

• A generic non-GitHub skill can run gh issue view and receive GitHub credentials.
• gh and git wrappers activate GitHub from any skill.
• Wrapper output/environment never contains the real token.
• Network policy is restored after success, failure, and timeout.
• GitHub manifest includes Actions but an installation lacking Actions can still run issue commands.
• gh workflow run without Actions approval returns admin remediation and no OAuth prompt.
• OAuth provider command without a stored token starts private auth and resumes.