Context
Our current subscription-auth story is Claude-specific: the two-pass post-compile sed tweak on .lock.yml files makes a CLAUDE_CODE_OAUTH_TOKEN work inside a gh-aw engine: claude run. README positions this as "use your Claude subscription in Actions."
OpenAI's Codex CLI also has subscription-based auth (ChatGPT Plus/Pro/Team login), and gh-aw supports engine: codex. So the category isn't Claude-exclusive — only our implementation is. Widening the wedge to "use your coding-agent subscription in Actions" (Claude or Codex) is a meaningful positioning upgrade if the technical path works.
Open questions — needs research, not implementation yet
- Credential shape. What does a ChatGPT-login session token / refresh token look like on disk after
codex login? Is it a single opaque string (like CLAUDE_CODE_OAUTH_TOKEN) or a multi-file credential blob?
- gh-aw codex engine compiled output. What secret/env var does
gh aw compile inject for engine: codex? Does it expect OPENAI_API_KEY, or does it have a subscription-aware slot? Grep the gh-aw source for the codex engine templates.
- Transform feasibility. Is there a post-compile text swap analogous to our two-pass sed that would let a ChatGPT-login token flow through? Or does Codex's auth model require a different injection point (e.g., writing a credentials file at runtime)?
- ToS boundary. OpenAI's ToS on programmatic use of ChatGPT subscription credentials — is it as permissive as Anthropic's OAuth flow (which we documented as ToS-acceptable in auth.md)? This gates whether we should productize the path even if it's technically feasible.
Non-goals (for this issue)
- Shipping a Codex install path. That's downstream of the research answering (1)–(4).
- Renaming the plugin or broadening marketplace positioning. Premature until feasibility is known.
Suggested next step
Time-box a ~half-day spike: codex login in a scratch container, inspect the credential files, compile a minimal engine: codex gh-aw workflow, and see whether any reasonable transform plumbs the subscription through. Drop findings in a comment on this issue before opening implementation issues.
Context
Our current subscription-auth story is Claude-specific: the two-pass post-compile
sedtweak on.lock.ymlfiles makes aCLAUDE_CODE_OAUTH_TOKENwork inside a gh-awengine: clauderun. README positions this as "use your Claude subscription in Actions."OpenAI's Codex CLI also has subscription-based auth (ChatGPT Plus/Pro/Team login), and gh-aw supports
engine: codex. So the category isn't Claude-exclusive — only our implementation is. Widening the wedge to "use your coding-agent subscription in Actions" (Claude or Codex) is a meaningful positioning upgrade if the technical path works.Open questions — needs research, not implementation yet
codex login? Is it a single opaque string (likeCLAUDE_CODE_OAUTH_TOKEN) or a multi-file credential blob?gh aw compileinject forengine: codex? Does it expectOPENAI_API_KEY, or does it have a subscription-aware slot? Grep the gh-aw source for the codex engine templates.Non-goals (for this issue)
Suggested next step
Time-box a ~half-day spike:
codex loginin a scratch container, inspect the credential files, compile a minimalengine: codexgh-aw workflow, and see whether any reasonable transform plumbs the subscription through. Drop findings in a comment on this issue before opening implementation issues.