Add General User Mode and Claim Gates for non-programmer Codex users

Open 💬 3 comments Opened Jun 5, 2026 by riosbotchen-source
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Product suggestion

Codex currently feels optimized for expert developers who can inspect diffs, logs, tests, and implementation details.

However, many future Codex users will be domain experts rather than software engineers. They may understand their own workflow deeply, but they cannot always verify whether a code-level change is truly correct.

This creates a trust gap.

Problem

In some workflows, Codex may report weak evidence as if it proves task completion:

  • tests passed
  • file generated
  • schema updated
  • feature exists
  • comparison script passed
  • no blockers

For expert developers, this may be enough to continue reviewing.

For general users, this can be misleading.

A passing test does not always mean the user-level task is complete. A generated file does not always mean the result is correct. A debug artifact should not be presented like a validation artifact.

Proposal

Codex could support first-class user modes:

1. Expert Mode

For software engineers.

  • concise diffs/logs/tests
  • faster autonomous execution
  • assumes the user can technically review the result

2. General User Mode

For domain experts who are not software engineers.

Codex should provide:

  • task contract before edits
  • no autonomous scope expansion
  • human-readable explanation of changes
  • clear distinction between what was verified and not verified
  • explicit statement of what each test proves and does not prove
  • no “done” claim without user-understandable validation evidence

3. Audit Mode

No edits.

Only inspect files, commands, logs, and evidence.

Every claim must cite a file path, command output, or concrete artifact.

Claim Gate

Codex should classify its conclusion instead of using a single “done” state:

  • investigation only
  • candidate generated
  • code regression passed
  • partial evidence passed
  • domain validation pending
  • domain validation passed
  • production ready

This would prevent a common failure mode:

Something passed, therefore the task is done.

That is often not true.

Evidence Manifest

For each artifact Codex produces, label it as:

  • debug only
  • candidate preview
  • validation artifact
  • final output

And include:

  • what this artifact proves
  • what it does not prove
  • whether it can be used to claim completion

Why this matters

Codex is powerful, but broader adoption requires more than coding capability.

Expert users need speed.

General users need trust boundaries.

A built-in General User Mode, Claim Gate, and Evidence Manifest would make Codex easier to trust outside pure software engineering workflows.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #25673

Powered by Codex Action

riosbotchen-source · 2 months ago

Related issues I found after filing this:

  • #24285 covers a similar completion-state / validation-gate problem in Codex Cloud PR workflows.
  • #21446 covers a related need for a production-ready mode for non-engineer users.

This issue is related to both, but the focus is narrower/different:

It proposes a general trust interface for non-programmer users:

  1. user modes,
  2. claim-level classification,
  3. evidence manifests,
  4. artifact type labels,
  5. preventing weak evidence from being presented as task completion.

So this is related to the existing validation-gate and production-readiness issues, but the requested product surface is specifically a claim/evidence UX layer rather than only PR validation or production-readiness planning.

grtninja · 1 month ago

Corroborating this need from an expert-user / production-agent workflow: claim gates are not only for non-programmers.

In a recent long-running Codex Desktop session, the user explicitly required an operator-visible local-agent workflow in a named application surface. The run generated substantial framework code, tests, status records, toggles, and backend activity, yet the defining capability—live tool-enabled repository work visible in that surface—remained absent. Intermediate artifacts were repeatedly discussed as progress, and at points visible state was described as working before the live integration had been verified.

The missing distinction was exactly the one proposed here:

  • scaffold created;
  • helper/unit tests passed;
  • production route wired;
  • integration live;
  • operation actually executed;
  • result visible in required surface;
  • user-level acceptance passed;
  • merged/deployed.

A large diff or passing test must not promote a requirement directly to done, especially when the PR itself lists the requested operational behavior as not included.

Suggested addition: claim gates should apply in Expert Mode too whenever the user supplies an explicit acceptance contract. Expert Mode can remain concise, but the final state should still name the strongest proven level and link the exact evidence. A backend-only artifact should never satisfy a user-visible acceptance requirement.