Repository navigation
Support T3 Claude Agent dispatch from Codex parents #175
Description
Codex-parent pstack workflows currently route Claude descriptors to the external headless runner. T3 already exposes app-owned Claude Agent delegation, but the shared provider mapping does not describe that route. Installations whose owner policy requires the app subscription route need an explicit supported path and a clear failure when it is unavailable.
Implementing in the maintained local fork as one coordinated change:
- Resolve the T3 Claude Agent provider and requested model/effort in the parent using live capabilities, preserving native same-provider and permitted direct CLI routes.
- Refuse the local fork's unsupported headless Claude path with a durable receipt before authentication or model execution.
- Update setup/probe instructions and regression coverage so they cannot select the removed path.
Keep one shared skill tree and the existing provider-dispatch boundary. No new coordinator, role configuration, timeout, or fallback. The headless-route refusal is a local owner-policy adaptation, not a claim that upstream must disallow all headless use.
Static checks and independent review will precede a PR. Exact-head installed behavior must satisfy the repository's live gate before merge or rollout. The existing verifier uses headless Claude, so this installation's permitted app-based verification route needs to be established without weakening that gate.
Activity
ericlitman commentedon Oct 14, 2026
On hold for now: testing this needs T3 installed on the maintainer's machine, which we'll set up later. Thanks for filing it.
ericlitman commentedon Oct 21, 2026
The hold condition from 2026-10-14 is met: T3 Code is installed on the maintainer's machine. Open Pstack's live gate and setup probes run Claude headless, so the change that refuses the headless route stays in your fork. We'd review a PR that adds T3's Claude Agent delegation as an additional external provider and leaves the headless route in place. Until one exists, this stays open and unscheduled.
ericlitman commentedon Nov 8, 2026
Closing as covered by #272, released in 1.19.0. Thanks for filing this. It shaped the T3 route.
What shipped, against this issue's three points:
provider-dispatch.mdreadsorchestrator_capabilitiesonce per run. It sends aclaude:*lane todelegate_taskon theclaudeAgentdriver when T3 offers the model and effort and allows cross-provider children. Otherwise the lane takes the standalone route: the native subagent, or the external runner./setup-pstackprobes T3-routed families throughdelegate_task. The live run of setup from T3 is tracked in Prove /setup-pstack from a T3 Code session #280.Live proof of the Codex-parent route, 2026-11-08, studio1:
gpt-6-lunaat medium effort. pstack 1.20.0 was installed in Codex, the current release.poteto-modeto dispatch one read-only lane,claude:claude-haiku-5-5@low, that reads a marker file holding a random UUID. The prompt did not contain the UUID, and the parent was told not to read the file.poteto-modeandprovider-dispatch.mdfrom~/.codex/plugins/cache/open-pstack/pstack/1.20.0/and calledorchestrator_capabilities. It then made onedelegate_taskcall withtarget: {providerInstanceId: "claudeAgent", model: "claude-haiku-5-5", options: {effort: "low"}},mode: "wait", and "Do not edit files." in the task.providerInstanceId: claudeAgent,model: claude-haiku-5-5,options: effort=low,status: completed,workState: result_available,hasPendingChildRuns: false,hasPendingQuestion: false,pendingApproval: null. The summary held the marker UUID.Not covered: a Codex parent's lane that falls through to the runner, and a fresh install of setup from a Codex T3 session.