Problem

All 8 bundled workflows that declare a top-level provider: hardcode provider: claude. This completely overrides DEFAULT_AI_ASSISTANT in .env, meaning users configured for Codex or Pi cannot run any bundled workflow without manually forking the YAML.

The executor at packages/workflows/src/executor.ts:284-285 unconditionally uses workflow.provider when set — DEFAULT_AI_ASSISTANT is only consulted when no provider is present. So a user with DEFAULT_AI_ASSISTANT=codex hits Not logged in · Please run /login from the Claude SDK on every bundled workflow run.

Affected bundled workflows (hardcoded provider: claude):

• archon-adversarial-dev.yaml
• archon-architect.yaml
• archon-fix-github-issue.yaml
• archon-interactive-prd.yaml
• archon-piv-loop.yaml
• archon-ralph-dag.yaml
• archon-refactor-safely.yaml
• archon-validate-pr.yaml

Of these, only some actually use Claude-specific node features (hooks, skills, allowed_tools, denied_tools, mcp, agents, betas, sandbox). Workflows without those features have no reason to lock the provider.

Additionally, 8 more bundled workflows have no provider: set at all (e.g. archon-assist, archon-feature-development, archon-comprehensive-pr-review) and correctly inherit DEFAULT_AI_ASSISTANT — confirming the pattern is inconsistently applied.

Proposed Solution

For workflows without Claude-specific node features: remove the top-level provider: claude entirely and let DEFAULT_AI_ASSISTANT / config defaults drive the choice.

For workflows that do use Claude-specific features (hooks, skills, mcp, etc.): keep provider: claude at workflow level, but document clearly in the YAML header that Claude is required and why. These features are no-ops or unsupported on other providers, so locking is justified — but it should be explicit and intentional, not accidental.

Longer term: The executor could apply Claude-specific node options only when the resolved provider is claude, and emit a warning (not an error) when a codex/pi run encounters a hooks: or skills: block — allowing the node to degrade gracefully rather than requiring the whole workflow to be locked.

User Flow

Before (current)

DEFAULT_AI_ASSISTANT=codex in .env
→ archon workflow run archon-fix-github-issue "Fix #367"
→ provider: claude (hardcoded) overrides DEFAULT_AI_ASSISTANT
→ Claude SDK: "Not logged in · Please run /login"  [!]
→ extract-issue-number: node_error
→ all 21 downstream nodes: skipped via trigger_rule
→ workflow_error: no successful nodes

After (proposed)

DEFAULT_AI_ASSISTANT=codex in .env
→ archon workflow run archon-fix-github-issue "Fix #367"
→ no top-level provider: (removed from generic workflows)
→ executor falls back to DEFAULT_AI_ASSISTANT=codex  [+]
→ workflow runs with Codex

Alternatives Considered

Scope

• Package(s) likely affected: workflows (bundled YAML files), workflows (executor graceful degradation)
• Breaking change? No — removing provider: claude from generic workflows makes them more flexible, not less
• Database changes needed? No
• New external dependencies? No

Security Considerations

• New permissions/capabilities? No
• New external network calls? No
• Secrets/tokens handling? No

Definition of Done

• Bundled workflows without Claude-specific node features have provider: removed (inherit from config)
• Bundled workflows that require Claude document the reason in a YAML comment
• Executor emits a warn (not error) when a Claude-specific node option is encountered on a non-Claude provider
• bun run generate:bundled re-run after YAML changes
• Tests covering provider inheritance from config