Repository navigation
Support Codex and Claude providers in delegate-backlog #95
Description
Summary
Extend delegate-backlog so it can delegate approved GitHub Issues to configurable coding-agent providers beyond GitHub Copilot, initially Codex and optionally Claude.
Current limitation
delegate-backlog v1 is hard-coded to GitHub Copilot coding agent. It verifies Copilot through GitHub’s assignable-actors API and delegates by assigning the issue. This does not work for repositories/accounts without a qualifying Copilot license.
The repository already contains Codex building blocks:
.github/scripts/run-codex-with-progress.sh.github/codex/builder-prompt.md.github/codex/architect-prompt.md
However, there is no Issue-to-agent workflow that invokes them, creates an isolated branch, and opens a PR.
Proposed direction
Introduce a provider adapter/configuration layer for delegate-backlog, for example:
{
"delegation": {
"provider": "codex-action"
}
}The first provider could be a repository-owned Codex GitHub Action/workflow:
delegate-backlogenriches the approved issue with its self-contained brief.- It triggers a workflow for the issue.
- The workflow checks out an isolated branch using the existing Codex runner/prompt infrastructure.
- Codex implements the issue, runs the repository checks, commits, pushes, and opens a PR.
- The workflow records issue → branch → PR state in a manifest/comment.
- The normal
pr-review/fix-prloop is applied to the resulting PR.
A Claude provider could follow the same interface using Claude Code or an equivalent GitHub Action and credentials.
Acceptance criteria
- The provider is configurable without changing the core delegation flow.
- The existing Copilot provider remains supported.
- A Codex provider can be selected and verified before delegation.
- Delegation produces one isolated branch and PR per issue.
- Assignment/trigger and resulting PR are verified by read-back; no PR numbers or agent availability are inferred.
- The run manifest tracks issue, provider, branch, PR, PR state, and review state.
- The implementation documents required GitHub permissions, secrets, and setup.
- Issue/comment text is treated as untrusted input and safely incorporated into prompts.
- Workflow triggers are restricted to trusted users/events and do not expose agent credentials.
- No automatic merge is performed.
- Failure and partial-delegation states are reported explicitly.
Notes
This should remain an explicit opt-in path: the async provider trades the dev-kit’s in-session gates for throughput, with quality gates re-applied during PR review.
Activity
atamanvega commentedon Sep 28, 2026
Thanks @hmamonk17 — the core idea is right: turning the hard-coded Copilot path into one provider among several is exactly the generalization
delegate-backlogneeds, and your acceptance criteria (read-back verification, untrusted issue/comment text, restricted triggers, provider in the manifest, no auto-merge, explicit partial-failure states) are provider-neutral and spot-on. This is also the "generic assign to a configured agent" that #84 deliberately deferred out of v1 — so this is the natural continuation of that RFC.A few points to shape before we build, mostly to keep it from leaning Codex-specific and to reconcile it with a constraint we just set:
1. Reframe
codex-action→ a provider-neutral "self-hosted Action" shape. There are really two kinds of provider, and Codex/Claude are the same kind:OPENAI_API_KEY) + runner + prompts;delegate-backlogtriggers it. Much heavier setup.So I'd define the config as the shape, not the vendor — e.g.
{"delegation": {"provider": "github-copilot" | "self-hosted-action", "action": {...}}}— with Codex and Claude as documented examples of the self-hosted shape. That keeps Codex out of the center and makes Claude a config, not a second special case.2. The
.github/codex/*files are this repo's own CI helpers, not shipped product.run-codex-with-progress.sh/builder-prompt.md/architect-prompt.mdlive in our.github/; they don't travel in the plugin, so a consuming repo won't have them. They're a fine reference for us, but the feature can't assume them — the self-hosted-Action provider has to be "bring your own workflow," with the kit documenting the contract (inputs/outputs, how the trigger and PR are verified) rather than shipping the runner.3. This collides with a constraint worth deciding explicitly, not in review. A repo-owned Action that implements issues is the real, legitimate version of the very pattern we just guardrailed against (the hallucinated
/builder+codex-builder.yml— #82/#83). And it's precisely the governance question in the hooks RFC (#92): the kit ships the extension points / the contract, never the handlers (the runner + prompts + secrets). If we agree on that line, the self-hosted-Action provider is "the kit defines and verifies the trigger contract; the repo owns the workflow" — which is clean. Let's settle that before code.Process: since this is design-level and overlaps #84/#92, I'd keep the shaping in the discussion (#93) and this issue as the tracking issue for the provider-abstraction work once we agree the shape — then a POC (Copilot stays; add one self-hosted-Action provider) gated by an eval, same as everything else. Nothing to build until the provider model + the governance line are agreed.
Net: keep your abstraction and acceptance criteria; generalize
codex-actionto a neutral self-hosted-Action provider; don't depend on our internal.github/codex/*; and decide the "contract-not-handlers" line up front. Sound right?