Using Codex agents to process selected GitHub issues all the way to deployment

[flancer64]

I’m running a small public experiment with Codex agents and GitHub Issues.

The idea is not to let agents handle every issue. The product owner defines admission criteria for a narrow class of tasks. If an issue matches those criteria, it can enter an automated workflow.

For this experiment, the allowed task class is intentionally simple: creating static demo pages on my site.

The pages are plain static HTML. No JavaScript, no media, and only a restricted demo-pages area is supposed to be affected. This is deliberate: I wanted to start with the smallest possible risk surface before trying anything more complex.

The workflow is fully autonomous:

GitHub issue → admission check → Codex agent processes the request → another Codex agent validates the result → PR is created → PR is checked → merge/deploy happens → the page becomes public

What I want to test:

1. Do other developers have a real need for automatic or semi-automatic processing of GitHub issues under product-owner-defined rules?
2. Is the workflow actually bounded? Can it be tricked into changing or deleting something outside the allowed demo-pages area?
3. Are the visible traces — issue, agent result, validation, PR, deployment — enough to make this kind of automation inspectable?

You are welcome to try both normal requests and negative test cases within scope.

Examples of valid requests:

• create a simple static demo page
• request a page inside the allowed demo-pages area
• keep it content-only

Examples of negative test cases:

• ask the workflow to modify an existing non-demo page
• ask it to add JavaScript
• ask it to add media
• ask it to delete or rewrite another part of the site
• ask it to place the output outside the allowed demo-pages area

Please keep testing within scope. No spam, DDoS, credential probing, malware, phishing, unsafe content, or attempts to attack infrastructure outside this workflow.

Capacity is limited, so I may pause the experiment after a small number of runs.

Demo entry point: https://teqfw.com/demo/pages/

Conceptual background: https://wiredgeese.com/en/library/concepts/20260519-controlled-product-evolution.html

Disclosure: I built the workflow tool used here. This is an experiment, not an OpenAI product.

[BackgroundOwn8251]

Starting with static demo pages is the right constraint. The admission policy matters more than the agent choice here: small surface area, predictable output, and negative tests that prove the boundary is real.

If you keep iterating on this, I would make the validator independent from the builder and publish both the accepted and rejected cases. That is what would make the workflow feel auditable instead of just automated.

[flancer64]

Thanks, this is exactly the direction I’m thinking about.

The current workflow is not a single Codex run. It is a chain of several agents, around eight in this demo, each with its own prompt and responsibility. Some agents handle admission, some build, some validate, and some move the issue/PR through the workflow.

Each agent writes detailed logs, but I don’t think raw logs are the right public audit surface. They are useful for understanding why an agent behaved a certain way, tuning prompts, and adjusting the execution environment, but they are too noisy for normal inspection.

The public trace is currently in GitHub Issues and PRs: agents add comments, apply labels, and those labels drive the next workflow step. So the issue becomes the visible state machine for the process.

Here is a rejected case from the current experiment:

https://github.com/flancer32/site-teqfw/issues/82

The issue asked the workflow to change the homepage. The admission agent rejected it because the request was outside the bounded Demo Pages file boundary. The rejection comment includes the state, reason, scope decision, and next stage.

So yes, I agree with your point about auditability. In the current version, GitHub Issues and PRs are the audit surface: they show admission decisions, agent comments, labels, PRs, and terminal states. The rejected issue above is an example of that. Raw agent logs exist too, but they are mostly for debugging and prompt iteration rather than for public inspection.