Feature Request: Read-only reviewer sidecar for Codex tasks

Summary

Add a read-only reviewer sidecar to Codex tasks.

The core idea is to let a Codex worker thread implement code while a separate reviewer thread audits the work, discusses findings with the user, tracks review status, and generates follow-up prompts for the worker thread.

The reviewer should not make code changes directly. It should act like a senior code reviewer attached to the current implementation thread.

Problem

Right now, a strong Codex workflow often requires multiple manual threads:

1. One Codex thread does the implementation.
2. A second Codex thread reviews the diff and finds issues.
3. The user discusses findings with the reviewer.
4. The user copies the reviewer’s feedback back into the worker thread.
5. The worker fixes the issues.
6. The reviewer re-checks and signs off.

This works well, but the experience is manual and context-heavy.

The missing product primitive is a native Reviewer Overlay attached to the active Codex task.

Proposed Feature

Add a Reviewer Sidecar Thread inside Codex.

The reviewer has:

• Read-only access to the current branch, diff, selected files, test output, and original task.
• A chat interface so the user can discuss findings.
• A persistent review state.
• The ability to classify issues as blocking, non-blocking, resolved, deferred, or dismissed.
• The ability to generate exact follow-up prompts for the worker thread.
• No permission to modify files directly.

Example Workflow

The user starts a Codex implementation task.

Then they open the reviewer sidecar and ask:

Review the current diff against the original task. Focus on edge cases, missing tests, and API compatibility.

The reviewer returns:

Review Result: Needs Changes

Blocking:
1. Missing test for reconnect behavior after Redis stream timeout.
2. Partial-fill cancellation path does not preserve order state correctly.

Non-blocking:
1. Naming in `OrderIntentMapper` could be clearer.
2. Add structured logging around rejected broker ACKs.

Suggested worker prompt:
"Fix the partial-fill cancellation state bug, add a regression test for Redis stream timeout reconnect, and preserve the existing public API."

The user can then chat with the reviewer:

Is finding #1 actually blocking?

Reviewer:

Yes, if reconnect can happen while orders are pending. If that state is impossible by design, downgrade it to non-blocking and add a comment or assertion documenting the assumption.

The user:

Defer the naming issue and generate the worker prompt.

Reviewer:

Deferred:
- Naming cleanup in `OrderIntentMapper`

Worker prompt:
"Fix the partial-fill cancellation state bug and add a regression test for Redis stream timeout reconnect. Do not rename public APIs or change existing behavior outside this bug fix."

Review State

The reviewer should maintain a small review board:

| Finding | Severity | Status |
|---|---:|---|
| Partial-fill cancellation bug | Blocking | Open |
| Missing reconnect test | Blocking | Open |
| Naming cleanup | Low | Deferred |
| Logging improvement | Medium | Open |

After the worker makes changes, the user can ask:

Re-review after fix.

The reviewer checks only the relevant changes and updates the board:

| Finding | Severity | Status |
|---|---:|---|
| Partial-fill cancellation bug | Blocking | Resolved |
| Missing reconnect test | Blocking | Resolved |
| Naming cleanup | Low | Deferred |
| Logging improvement | Medium | Open |

Then it can produce:

Sign-off: Approved with non-blocking follow-up

Blocking issues are resolved. Remaining item is logging improvement, which can be handled separately.

Reviewer Modes

Useful modes could include:

• General code review
• Security review
• Test coverage review
• Performance review
• Architecture review
• Backwards compatibility review
• Migration safety review
• Requirements review

Key Product Constraint

The reviewer should be conversational, not just a static lint report.

The user needs to be able to ask:

• “Is this really blocking?”
• “Show me the exact file and line.”
• “What is the minimal fix?”
• “Can this be deferred?”
• “Generate the prompt I should send to the worker.”
• “Re-review after the fix.”
• “Sign off.”

Why This Matters

This creates a clean separation of responsibilities:

| Role | Responsibility |
|---|---|
| Worker Codex thread | Implement the change |
| Reviewer sidecar | Challenge the implementation |
| User | Make final decisions and control merge direction |

This mirrors a real engineering workflow:

developer → pull request → reviewer → change request → fix → approval

But compressed into a single Codex workspace.

Suggested Names

• Reviewer Overlay
• Reviewer Sidecar
• Shadow Reviewer
• Review Companion
• Sign-off Agent
• Code Auditor
• PR Guardian

Best First Version

A strong MVP could be:

1. Add a read-only reviewer sidecar to a Codex task.
2. Let it inspect the current diff and original prompt.
3. Let the user chat with it.
4. Let it track findings.
5. Let it generate a worker follow-up prompt.
6. Let it re-review after changes.
7. Let it produce a final sign-off.

This would make Codex feel less like one agent trying to build and grade its own work, and more like a proper engineering loop with a builder, reviewer, and human tech lead.