DEV Community

Fenju Fu
Fenju Fu

Posted on

I Wired Open-Source Codex into Astron: A Real 58-Second Test-Fix Run

#codingagent #opensource #mcp #workflow

Everyone is talking about open-source coding agents. I wanted a narrower answer: can one run inside a real workflow, obey hard boundaries, change the right file, and leave evidence another process can verify?

So I connected openai/codex 0.149.0 to a local Astron workflow through MCP. This was not the Codex desktop app and not a UI mockup.

The Chinese Astron run completed in 58.309 seconds. Codex changed one source file. An external verifier then moved the repository from 0/2 passing tests to 2/2. No test file changed. Nothing was committed, pushed, or published by the agent.

Real Astron UI running open-source Codex against a local repository

The bug

The fictional Node.js repository summarized workflow node states. Its implementation treated every non-success state as a failure:

const failed = nodes.filter((node) => node.status !== "succeeded").length;
Enter fullscreen mode Exit fullscreen mode

That incorrectly counted skipped nodes as failed. The business rule was simple: only an explicit failed state belongs in the failure count.

const failed = nodes.filter((node) => node.status === "failed").length;
Enter fullscreen mode Exit fullscreen mode

Before the patch, both tests failed. After the patch, the external Node test runner reported two passing tests and zero failures. git status showed only src/run-summary.js modified.

The Astron workflow

The workflow deliberately had only three nodes:

  1. Task input receives the repair request and its restrictions.
  2. Codex MCP calls the open-source codex tool through a local SSE adapter.
  3. Repair evidence returns the tool result and diff summary.

The important MCP settings were operational, not decorative:

  • toolName: codex
  • mcpServerUrl: http://host.docker.internal:8787/sse
  • sandbox: workspace-write
  • cwd: the dedicated fictional repository
  • approval-policy: never
  • developer instructions that forbid commits, pushes, publishing, and secret access

Astron supplied the repeatable task boundary. Codex performed the code edit inside that boundary.

The prompt was intentionally strict

The repair request said:

  • edit only /workspace/src/run-summary.js
  • do not edit tests
  • do not run shell commands
  • use apply_patch for the smallest change
  • do not commit, push, or publish
  • return the changed file and a diff summary
  • let an external verifier run tests

This matters. A vague “fix the tests” prompt can reward the wrong behavior, including changing tests to match broken code. The workflow made the allowed write scope and the validation owner explicit.

It was not zero-config

The first attempt failed before Codex could read the repository because bubblewrap could not create a user namespace.

The working setup required three compatibility fixes:

  1. Native Windows codex mcp-server could create a session, but its shell helper failed in this environment, so Codex ultimately ran in a dedicated Linux container.
  2. The local Astron deployment needed an explicit MCP_BASE_URL.
  3. The container seccomp profile needed the namespace-related syscalls required by bubblewrap.

After those fixes, all three Astron nodes completed successfully and Codex returned the expected minimal repair summary.

This is therefore not an official, zero-configuration Astron–Codex integration. It is a real local integration with reproducible evidence and documented boundaries.

How to reproduce the pattern

  1. Install open-source Codex and start its MCP server.
  2. Bridge stdio to local SSE with mcp-proxy.
  3. Import the Astron workflow and replace cwd with a low-risk test repository.
  4. Start with a deterministic failing test and forbid test edits and repository publishing.
  5. Validate the returned patch with an independent test command and git diff.
  6. Let a human decide whether the verified change should be committed.

The practical lesson is simple: the next useful milestone for coding agents is not a more impressive chat answer. It is controlled execution that can be repeated, inspected, and independently verified.

Resources

Top comments (0)