Skip to content

Feature request: Pluggable agent support (Codex CLI, opencode, and beyond) #23

@Simon-BEE

Description

@Simon-BEE

Feature request: Pluggable agent support (Codex CLI, opencode, and beyond)

Summary

Chief's orchestration logic — the Ralph loop, task queue, git workflow, TUI — is inherently agent-agnostic. The only tight coupling today is the hardcoded calls to the claude binary. Introducing a thin Provider abstraction would let users choose their preferred AI coding agent while keeping Claude Code as the default with zero breaking changes.

The first alternative target is OpenAI Codex CLI; the architecture should make it straightforward to add others like opencode later.


Motivation

  • Some teams or individuals already use Codex CLI or are experimenting with alternatives like opencode
  • Chief's value lies in the orchestration layer (PRD → stories → autonomous loop → commits), not in a specific LLM backend
  • A pluggable architecture makes the project more tool-agnostic, broadens its audience, and invites contributions for new runners

Proposed approach

Interface — A Provider interface in internal/loop/provider.go:

type Provider interface {
    Name() string
    CLIPath() string
    LoopCommand(ctx context.Context, prompt, workDir string) *exec.Cmd
    InteractiveCommand(workDir, prompt string) *exec.Cmd
    ConvertCommand(workDir, prompt string) (cmd *exec.Cmd, mode OutputMode, outPath string, err error)
    FixJSONCommand(prompt string) (cmd *exec.Cmd, mode OutputMode, outPath string, err error)
    ParseLine(line string) *Event
    LogFileName() string
}

Each agent CLI has different flags, output formats, and conventions. The interface captures the four interaction modes Chief needs (autonomous loop, interactive session, one-shot conversion, JSON fix) plus a per-provider JSONL parser that maps agent-specific events to Chief's internal Event types.

Implementations in internal/agent/:

  • ClaudeProvider — current behaviour, wraps the claude binary
  • CodexProvider — wraps codex exec --json --yolo for the loop, codex exec --output-last-message -o <file> for one-shot tasks

Configuration — three layers, in priority order:

# CLI flag
chief --agent codex --agent-path /usr/local/bin/codex

# Environment variable
CHIEF_AGENT=codex CHIEF_AGENT_PATH=/usr/local/bin/codex chief

# .chief/config.yaml
agent:
  provider: codex
  cliPath: /usr/local/bin/codex   # optional

Resolution centralised in agent.Resolve(): flag → env → config → default (claude). Unknown provider names return an explicit error.


Non-goals / guarantees

  • Claude Code remains the default — zero impact on existing users and configs
  • No changes to the PRD format, story structure, prompt templates, or TUI behaviour
  • Each provider implementation is responsible for mapping its own CLI flags and output format; the rest of Chief stays untouched
  • The <chief-complete/> / <ralph-status> protocol lives in the shared prompt, not in provider code — any agent that follows instructions will produce the right markers

Future runners

Once the abstraction is in place, adding a new agent is a contained task:

  1. Create internal/agent/<name>.go implementing Provider (~70 lines)
  2. Create internal/loop/<name>_parser.go mapping the agent's JSONL to Chief events (~100 lines)
  3. Add one case in agent.Resolve()

No other file needs modification. Potential candidates:

  • opencode — open-source, multi-model
  • Any future CLI-based coding agent

Implementation

I have a working implementation ready with full test coverage. Happy to open a PR if this direction aligns with the project's vision — or to discuss the interface design first if you'd prefer.

Simon-BEE#1

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions