Ticketly
Codex planning · Human-in-the-loop

How to use human approval gates with Codex.

Let Codex inspect the repository, but pause before it turns observations into a plan. Confirm the evidence, approve the release scope, and review the backlog before implementation.

Codex planning workflowThree approval gatesFirst-party controlled evidence
The three gates
1. confirm repository findings
2. approve the release scope
3. review the generated backlog

Direct answer

Should Codex plan and implement without human approval?

No. Ask Codex to inspect the repository and show its findings first. A person then confirms what is true, approves the release scope, and reviews the dependency order and acceptance criteria. Implementation starts only after those decisions are explicit.

Ticketly helps structure, validate, and export the confirmed plan. It does not decide the roadmap or silently resolve a product question that still needs a person.

Why the pauses matter

Repository evidence and product judgment are different

Codex can explain what the codebase appears to implement, find dependencies, and identify unknowns. Those observations do not tell it which customer problem matters most or what the next release should prioritize.

Use the repository as evidence, not as the roadmap.

A feature can exist in code and still be the wrong priority. A missing implementation can be intentional. The owner must confirm the desired outcome before planning begins.

Gate 1 · Confirm findings

Ask Codex to inspect, summarize, and stop

Start with a confirmed product goal. Ask Codex to locate the relevant implementation, describe the current behavior, cite the files it used, list unknowns, and wait for corrections.

Inspection prompt
inspect this repository for the confirmed goal
separate current facts from assumptions
cite the relevant files and list unknowns
stop and wait for me to confirm the findings

Correct missing context now. Otherwise, a technically coherent plan can still be based on a false description of the product.

Gate 2 · Approve scope

Decide what belongs in this release

Review the proposed work in three groups:

  • Required now: changes needed for the confirmed outcome.
  • Deferred: useful ideas that are outside this release.
  • Unresolved: decisions that need user, business, privacy, or technical input.

Keep unresolved items visible as clarifications. Do not let the agent turn an unanswered decision into an invented requirement.

Gate 3 · Review the backlog

Check whether another person or agent can execute it safely

Before implementation, verify that every task has:

  • A clear outcome and testable acceptance criteria.
  • Dependencies that match the required execution order.
  • Enough context to avoid repeating repository discovery.
  • No hidden product decision presented as a technical fact.
  • A deliberate owner or an intentionally blank assignee.

Ticketly can validate the structure and render Markdown and CSV outputs. A person still approves the plan that those outputs represent.

Controlled first-party evidence

One real repository run kept a product decision unresolved

The Ticketly team ran this workflow on Ticketly's own growth site. The reviewed goal produced 5 epics and 18 dependency-ordered tasks. One measurement decision stayed as a clarification instead of being guessed, and the final graph passed with zero structural errors or warnings.

5epics
18tasks
1clarification
0errors
0warnings
Evidence boundary

This is a controlled first-party demonstration, not a customer case study, testimonial, adoption claim, or performance benchmark. Read the complete post-MVP repository run.

Responsibility boundary

Who decides what in the workflow?

  • Codex: inspects the repository, reasons about the implementation, and explains evidence and unknowns.
  • Ticketly: provides the planning workflow, validates the confirmed ticket graph, and exports reviewable Markdown and CSV files.
  • The product owner or team: chooses the goal, corrects findings, approves scope, resolves clarifications, and authorizes implementation.

Reusable workflow

Prompt Codex to pause at every decision boundary

Prompt
use Ticketly to plan this confirmed product goal
inspect the repository and show evidence before planning
pause for my approval of findings and release scope
keep unresolved decisions as clarifications
validate the backlog, then wait before implementation

New to the integration? Follow the complete Ticketly for Codex guide before using this checklist.

FAQ

Common questions about Codex approval gates

Should Codex start coding immediately after inspection?

No. First confirm the findings, approve the release scope, and review the generated backlog. Inspection and implementation should be separate decisions.

Who decides the product roadmap?

A person responsible for the product or release. Codex can provide repository evidence, but code does not reveal which outcome the business should prioritize.

What happens when a product question is unresolved?

Keep it as a visible clarification and block the dependent work if necessary. Do not let the agent guess the answer.

Does the Ticketly CLI inspect the repository itself?

No. Codex performs repository inspection and reasoning. Ticketly supplies the workflow and local validation/export engine.

Install Ticketly for Codex