feat(provider): Add Pi provider support across runtime and action#242
feat(provider): Add Pi provider support across runtime and action#242
Conversation
Thread provider selection through config, CLI, SDK, and GitHub Action flows so runs can target Claude or Pi consistently with provider-aware auth and telemetry. Add provider-specific tool policy defaults for the core loop, including Pi shell/read/write/edit tools while preserving skill-level allow/deny overrides. Also record provider metadata in outputs and add regression coverage for provider wiring. Co-Authored-By: GPT-5 Codex <noreply@anthropic.com>
dcramer
force-pushed
the
feat/pi-provider-core-loop
branch
from
795e500 to
5bc7359
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| */ | ||
| export function verifyAuth({ apiKey }: { apiKey?: string }): void { | ||
| export function verifyAuth({ apiKey, provider = 'claude' }: { apiKey?: string; provider?: Provider }): void { | ||
| void provider; |
There was a problem hiding this comment.
Auth verification ignores provider, always checks Claude CLI
High Severity
verifyAuth accepts a provider parameter but immediately discards it with void provider. When the Pi provider is used without an API key, the function still checks for the claude binary and throws Claude-specific error messages ("Claude Code CLI not found on PATH"). In the action path, action.yml intentionally skips Claude Code CLI installation when provider is 'pi', so this check will always fail with a confusing, provider-incorrect error for Pi users who rely on CLI-based auth.
Additional Locations (1)
| const envProvider = process.env['WARDEN_PROVIDER']; | ||
| if (envProvider === 'claude' || envProvider === 'pi') return envProvider; | ||
| return 'claude'; | ||
| } |
There was a problem hiding this comment.
CLI provider precedence inverted versus action path
Medium Severity
resolveProvider in the CLI path gives configProvider (from warden.toml defaults) higher precedence than cliProvider (the --provider flag). This means a user passing --provider pi on the command line gets overridden by the config file's defaults.provider. In contrast, resolveActionProvider correctly gives the explicit input highest precedence. The CLI --provider flag becomes effectively inert when a config file sets defaults.provider.
Additional Locations (1)
![sentry-warden[bot]](https://avatars.githubusercontent.com/in/2755838?s=60&v=4){kind=small}
| apiKey: string, | ||
| maxRetries?: number | ||
| maxRetries?: number, | ||
| provider: Provider = 'claude' |
There was a problem hiding this comment.
Provider parameter not threaded through fix evaluation call chain
The evaluateFix function adds a provider parameter with default 'claude', but the caller in src/action/fix-evaluation/index.ts (line 206) doesn't pass it, and evaluateFixAttempts doesn't accept a provider from its callers. This means fix evaluation will always use Claude regardless of the configured provider, breaking the PR's goal of consistent provider selection across CLI and GitHub Action paths.
Verification
Verified by reading: (1) judge.ts lines 212-237 showing evaluateFix signature with provider default, (2) index.ts lines 206-211 showing evaluateFix called without provider argument, (3) index.ts line 82-89 showing evaluateFixAttempts signature lacks provider parameter, (4) pr-workflow.ts lines 395-407 showing evaluateFixAttempts called without provider. The provider configuration set in warden.toml or action inputs is not threaded through this call chain.
Also found at 1 additional location
src/action/inputs.ts:91-91
Identified by Warden find-warden-bugs · 5LW-JGD
1 participant
Add first-class provider selection so Warden can run core analysis with Claude or Pi across CLI and GitHub Action paths.
Thread provider through config resolution, trigger execution, auth/key lookup, SDK runner options, and output metadata so the selected provider is applied consistently end-to-end.
For Pi runs, the core loop now applies provider-specific default tool policy that includes shell/read/write/edit support while preserving skill-level allow/deny overrides.
This also includes targeted simplifications in config/action/CLI provider parsing and a small tty test hardening for FORCE_COLOR in environments that export NO_COLOR.