Can GitHub Actions Use Your ChatGPT Plan for Codex?

Here is the honest answer to the Reddit-shaped question. Mechanically, a ChatGPT plan session can be made to work in GitHub Actions; the CLI’s login is a file, and files can be moved. But the official action documents API-key auth, OpenAI’s terms tie each account to exactly one user, and a personal session in a pipeline that teammates and PRs can trigger stops being personal the first time someone else pushes. The clean patterns are three: an API key in shared CI, a runner only you use, or a hosted endpoint where the plan session stays in a container that is yours alone.

Why the question keeps coming up

The motive is sound, which is why the question deserves a straight answer. Codex is included in ChatGPT plans, and the same review job that meters API tokens per diff would ride a subscription the developer already pays for. Multiply by every PR on a busy repo and the meter is real money; our auth comparison walks the billing math. People are not trying to cheat; they are trying to use capacity they bought.

The problem is not the desire for plan pricing. The problem is where the credential ends up.

What the official action expects

OpenAI’s GitHub Action authenticates with an API key from repository secrets, and the action guide shows the full setup. That design choice is information. CI built for teams assumes impersonal credentials: scoped to a project, capped by a budget, dead one click after a leak. The action asking for a key is OpenAI telling you what shared CI should run on.

A key also fails gracefully. Rotating it is a non-event. Nothing about your personal account, your chat history, or your other devices is in the blast radius.

The auth.json route, examined honestly

The mechanical route exists and we will not pretend otherwise: ~/.codex/auth.json holds the CLI’s session after login, and a workflow could be fed one through a secret. We are not going to walk through it, because every property that makes it work makes it a bad idea on a shared runner:

• It is a password, functionally. The file is a live session for your ChatGPT account. GitHub masks secrets in logs, but anyone who can edit a workflow can exfiltrate one, and forks plus pull_request_target mistakes have leaked plenty.
• It makes the account shared in practice. Every teammate’s push now runs work as you, on your login. OpenAI’s Terms of Use tie an account to one user; this arrangement stops looking like one user the moment a second person triggers it.
• It fails silently. Sessions lapse and refresh out from under a copied file. Your pipeline’s auth now depends on state no secret store understands.

Device-code sign-in on headless machines is documented, intended functionality, but OpenAI has the final call on how accounts may be used, and a personal session spread across a team’s CI is on the wrong side of the line it has drawn. The session-handling rules are covered in codex login without a browser.

Three patterns that stay clean

Pattern	Where the plan session lives	Who can spend it	Best for
API key in shared CI	Nowhere; metered key instead	Anyone with repo write, capped by key budget	Team repos, PR review gates
Self-hosted runner only you use	The runner’s ~/.codex, via device auth	You	Solo repos, personal automation
Hosted endpoint (Codex Hosted)	An isolated container tied to your account	Holders of a revocable endpoint key you issue	Plan-priced bulk work, CI as one of many callers

The second pattern is just a machine that happens to take CI jobs:

jobs:
  nightly-triage:
    runs-on: [self-hosted, codex] # a box you alone use, signed in once via device auth
    steps:
      - uses: actions/checkout@v4
      - run: codex exec --sandbox read-only "Triage yesterday's CI failures; group by root cause."

The third moves the session out of CI entirely. With Codex Hosted, the device-code sign-in happens directly between you and OpenAI, the session lives in a container only your account uses, and your workflow holds nothing more sensitive than a revocable key:

- name: Ask Codex through the hosted endpoint
  env:
    PROXYLLM_API_KEY: ${{ secrets.PROXYLLM_API_KEY }}
  run: |
    curl -s https://api.proxyllm.ai/v1/chat/completions \
      -H "Authorization: Bearer $PROXYLLM_API_KEY" \
      -H "Content-Type: application/json" \
      -d '{"model": "gpt-5-mini", "messages": [{"role": "user", "content": "Summarize the risk in this diff: ..."}]}' \
      | jq -r '.choices[0].message.content'

The leak math flips: a leaked PROXYLLM_API_KEY is a rotation in our dashboard, not a compromised ChatGPT login. Responses on the Codex lane arrive complete rather than streamed, which CI never notices, and when a plan window exhausts the request falls back to a second connected account or your own API key. CI keys with per-repo caps are covered on the GitHub Actions integration page.

Which one to pick

Decide by who triggers the work. Teammates and external PRs: API key, full stop. Only you, on hardware you control: device auth on your own runner is free and fine. You, at volume, across CI plus agents plus scripts: the hosted endpoint, because it keeps plan pricing without ever parking your login inside someone’s pipeline.

A repo secret should be revocable; a ChatGPT session is not a secret, it is your account. Build on the patterns that keep those two categories apart, and the plan pricing you wanted is still on the table: the pipeline guide covers the key-backed half, and Codex Hosted is the plan-backed half done properly.