Do You Need Codex for Every Step? We Tested ChatGPT + GitHub Actions as a Cloud Runner

1. The problem: a coding specialist is often used as a test runner

OpenAI positions Codex for real engineering work such as feature implementation, complex refactors and migrations. Those are high-value tasks. Yet in an AI-assisted workflow, the same agent can easily end up spending time on repository checks, repeated tests, browser smoke runs and evidence collection.

Our question was narrower: can reasoning and repetitive execution be separated? If ChatGPT decides what needs to be checked and an existing cloud runner performs only approved tests, then the coding specialist can enter when the evidence says code must actually change.

2. We first considered MCP plus a VPS

A remote MCP server is an obvious architecture: expose approved tools, let ChatGPT call them and keep the development machine somewhere in the cloud. It can be powerful, but it also introduces server operations, security boundaries, network exposure and another cost surface.

There is also a product-availability constraint. As of September 12, 2026, OpenAI says full MCP support with write/modify actions is rolling out in beta to Business, Enterprise and Edu. Pro users can build apps but current full MCP access is more limited. For our use case, a permanent remote server was more infrastructure than the experiment needed.

3. We changed the question: divide the roles instead of giving one agent a server

The architecture uses five roles. ChatGPT analyzes the situation and chooses the next validation. GitHub holds the request, state and evidence. A GitHub-hosted runner executes only fixed allowlisted tasks. Playwright opens a real browser and records what happened. Codex handles implementation, difficult debugging, refactors and multi-file changes.

The runner is deliberately not an autonomous coding agent. External text never becomes an arbitrary shell command. The useful property is not maximum autonomy; it is a narrow execution surface whose result can be inspected before another decision is made.

4. Architecture: brain, state, hands, eyes and specialist

5. What the Method & Miles PoC actually tested

We ran the experiment in the real private repository, but we are intentionally not publishing internal file names, branch names, workflow names, run IDs, commit hashes or secret identifiers. The public value is the architecture and the evidence boundary, not our private implementation map.

• Repository validation: run the existing non-production validation entry point in a hosted runner.
• Fixed Node test: execute one pre-approved test target with a fixed command.
• Browser smoke: build locally inside the runner and launch Playwright Chromium.
• Responsive evidence: capture 390×844 and 1280×720 screenshots.
• Structured result: preserve PASS/FAIL/ERROR, failures, timestamps and artifact metadata.
• Round trip: ChatGPT hands off the task, the runner executes it, and ChatGPT reads the returned evidence before deciding again.

6. What passed — and one design that failed

[Experiment result] In Phase 1, repository validation, the fixed Node test and the Playwright Chromium browser smoke all passed. The browser run produced both mobile and desktop screenshots.

[Experiment result] In Phase 2, ChatGPT wrote a structured request, GitHub Actions started the runner automatically, the fixed Node test passed, structured evidence was produced and ChatGPT retrieved the result. The full handoff-and-readback loop worked.

[Experiment result] An earlier issue-based trigger was abandoned after we found it overlapped with another production-side trigger. We replaced it with an isolated handoff path. That failed design mattered: an AI workflow is not safe merely because the command itself is allowlisted; the trigger boundary also has to be isolated.

7. Why the split is useful

1. Less local-PC dependence: validation runs on a GitHub-hosted VM.
2. No dedicated VPS for this scope: there is no server to keep alive.
3. No new execution platform: the PoC did not add a separate paid test service or agent framework.
4. Routine QA moves out of the specialist: checks, browser smoke and screenshots have their own layer.
5. Evidence survives the run: logs, structured results and screenshots are separate from the AI’s confidence.
6. The execution surface stays narrow: fixed allowlisted tasks block arbitrary command payloads.

[Hypothesis] We have not measured a Codex usage-reduction percentage. The PoC proves that some non-modifying validation work can be routed elsewhere; it does not prove a universal savings rate.

8. Cost: ‘zero incremental execution cost’ has conditions

GitHub says standard hosted-runner usage for private repositories draws from the included Actions allowance for the account plan, and usage beyond that allowance can be billed. GitHub Free currently includes 2,000 minutes per month and Pro 3,000 minutes. So ‘GitHub Actions is unlimited and free’ would be inaccurate.

[Experiment result] Our PoC added no VPS, database, paid test platform or paid agent framework. [Constraint] More frequent browser runs will consume runner minutes and artifact storage, so usage still needs a budget. We did not calculate a monthly dollar saving from Codex.

9. Cloud Runner vs Codex: a simple decision table

That split is consistent with how OpenAI describes Codex: a coding agent for end-to-end engineering work. The Cloud Runner is not competing on intelligence; it is reducing how often intelligence is needed for deterministic execution.

10. Who this helps — and where it stops

This pattern is attractive for vibe coders, indie hackers, solo builders, non-developer founders and small teams that already use ChatGPT and GitHub. It is especially useful when code generation is easy but verification keeps falling back to one person’s laptop.

It is not a turnkey product for every repository. If you need autonomous code modification, open-ended shell exploration, complex interactive debugging or a different command surface for every project, use a proper coding agent or design a more capable development environment. Do not widen an allowlisted runner until it quietly becomes an unrestricted remote shell.

11. Final judgment: route work, do not replace the specialist

The most useful result was not ‘we replaced Codex.’ It was that reasoning, execution, verification and code modification can be managed as different responsibilities. That makes cost, usage, security and evidence easier to reason about.

ChatGPT decides. Cloud Runner executes and verifies. Codex changes code when code must change.

This is still a small experiment, not a universal development platform. But it was enough to prove that a safer, inspectable loop can be built with tools we already had.

Related reading: how to choose AI tools, how to audit free AI limits, and how to pilot browser agents before rollout.