Review a Code Change with Cue Voice and Codex

Choose your input route

Use Cue when the review question starts in another app. You may notice a risk while reading a specification, checking an issue or trying the changed screen. Dictate the intended behavior and what must stay true into a scratch note, then review the text and carry it into Codex. Cue is useful here for gathering the review brief across apps; the exact diff still needs to be selected in the review environment.

Stay in Codex when the relevant project, diff and review question are already there. Type or paste the short request directly and use the review controls described below. You can complete this exercise without Cue. Adding Cue makes sense when speaking or collecting context outside that task helps you state a better review question. Review quality still depends on the supplied evidence and the reviewer’s checks.

Cue Dictation into an external app

This is the route used below. Cue puts your words into a focused scratch note or supported text composer. Check the wording, then explicitly send the brief to Codex for a read-only review. No Cue connector is required. Only the material you supply travels with the handoff; other conversations, files and permissions do not automatically follow.

Codex connector inside Cue

This is a separate way to use an external Agent from Cue. Verify the connection, sign-in, project and permissions for that route first, and check its account and billing. A visible Codex option does not prove it is ready. The Codex app's review pane and menus described below are not instructions for a connector inside Cue.

Cue Agent with a hosted model

Ask Cue Agent to organize the source material you provide into a draft review brief, then check the brief against those sources. Selecting an OpenAI model for Cue Agent does not start Codex or give a separate Codex task access to your repository. Hosted model access and billing follow your Cue account; confirm external Agent access separately.

Try the small-patch review exercise using Dictation followed by an explicit text handoff. Speak the review goal, then attach R-01 through R-03 as written. Ask for findings without editing. You are done when you can trace each finding to an exact expression and triggering input, and distinguish an illustrative finding from a check actually run.

Capture the review question where you notice the risk

A review is easier to act on when it has one question. “Review everything” can produce style suggestions while missing the behavior you care about. A more useful spoken request is: “This patch makes a zero count visible. Check whether missing counts still use the old empty-state label. Do not edit anything yet.”

1. Keep the specification or affected screen visible, then focus a scratch note or the intended task input. Invoke the Dictation shortcut shown in Cue Settings, confirm recording, speak the review goal, stop, and inspect the inserted text after processing.
2. Preserve exact identifiers by copying them from the source. Review the transcription of numbers, negations and branch names before sending. If you want Cue Agent to organize the note, ask for a draft brief and explicitly supply the required excerpt.
3. Open the correct Git project in Codex. Its review pane shows repository changes, which can include your edits and other tools' edits, not only Codex's last response. Confirm what belongs to this task before requesting a review.
4. Transfer the checked brief explicitly. This can be a pasted note or a dictated follow-up into a focused text composer. Cue's model selector does not select the runtime or grant access for a separate Codex task.

You do not need a Cue-to-Codex connector for this manual route. If you choose an external Agent inside Cue instead, verify that route's connection, sign-in, project and permissions first. Do not assume it has the Codex desktop app's menus or automatically receives earlier chat history. See Cue with coding Agents for the distinction.

Choose the exact diff before asking for findings

For the Codex app, OpenAI's code review documentation describes /review in the composer, with options for uncommitted changes or review against a base branch. The review pane also distinguishes staged, unstaged, commit, branch and last-turn views. These are Codex app controls, not Cue commands, and their availability depends on the installed version.

• Uncommitted work: inspect staged and unstaged files. Tell the reviewer which files are in scope and which existing changes belong to someone else. Do not assume “last turn” covers everything you plan to ship.
• A branch change: select the actual intended base branch, not whichever name looks familiar. Record the base and head commit IDs if you need the review to be reproducible later.
• One commit or supplied patch: name the commit or attach the patch with enough surrounding implementation to interpret it. If you paste only a snippet, label the review as snippet-only.

For a customized task, paste the brief below and request a read-only review of that exact scope. The built-in review and a free-form prompt are different entry points; do not assume constraints typed elsewhere were automatically attached to the review. Check the review task's context. Never switch off permissions just to make a review run.

Practice: find the regression in a plausible small patch

This fictional exercise supplies a tiny diff and a behavior contract. It can be reviewed as a text-only exercise; it is not a recorded Codex run and does not need access to a production repository.

Source R-01 — contract: A zero count must display 0 results. null and undefined mean missing and must display No count. Positive counts must remain visible. Other input validation and singular grammar are outside this task.

Source R-02 — proposed diff in result-label.mjs:

 export function resultLabel(count) {
-  return count ? `${count} results` : 'No count';
+  return count !== null ? `${count} results` : 'No count';
 }

Source R-03 — patch author's claim: “This fixes zero counts and keeps missing values unchanged.” Treat that sentence as a claim to check, not evidence that tests ran.

Ask: “Review R-02 against R-01. For each concrete regression, give the trigger, changed expression, actual versus expected behavior, and the smallest check that would prove it. Keep unanswered questions separate. Do not implement a fix.”

An illustrative finding is: “The added condition excludes null but accepts undefined. Calling the changed function with undefined produces undefined results, whereas R-01 requires No count. The expression count !== null is the relevant changed code. Add a check of undefined alongside zero, null and a positive count.” This conclusion follows from the supplied JavaScript; it is not a claim that Codex found or tested it.

Notice what the finding does not invent: a customer impact count, a production outage, a line number from an unseen repository or an unrelated security risk. On a real diff, include the verified file and line range. On this snippet, naming the exact expression is more honest than manufacturing a source location.

Copy a focused review brief

Replace the bracketed fields, including the exact scope, before sending to Codex.

Task: Review this change. Do not modify files or publish a review.
Project: [confirmed repository]
Diff scope: [uncommitted files, or base/head commit IDs]
Intended behavior: [what the change must accomplish]
Invariants: [behavior that must remain unchanged]
Sources: [specification IDs, reproduction, relevant files or patch]
Priority: correctness and regressions in this scope, not style cleanup.
For each finding return:
- verified file/line or exact supplied expression
- triggering input or user action
- actual versus expected result
- evidence from the change and its call path
- a minimal reproduction or regression check
- impact and uncertainty, without invented frequency or severity
Put questions and unverified hypotheses in a separate section.
If a check was not run, say so. A proposed test is not test evidence.
If no confirmed findings remain, state scope and residual risks.
Do not fix, commit, push, merge or deploy. Wait for my next instruction.

Turn findings into a decision, not a blanket approval

Read each finding beside its source. For R-02, check that the changed function still handles zero and null, then test undefined. A finding about an untouched helper should explain how the patch reaches it; otherwise it may be unrelated backlog work. A long report is not necessarily a useful review.

Classify the outcome in plain language:

• Confirmed regression: supported by the contract and a reproducible case. Decide whether to authorize a bounded fix, then rerun the relevant checks.
• Question: an assumption needs a source, such as whether undefined can reach the function in the actual app. Resolve it with the call path or specification, not the reviewer's confidence.
• Out of scope: useful cleanup can be recorded separately. It should not expand the current patch silently.
• No confirmed findings: the reviewed scope had no substantiated findings. That is not proof of correctness, a completed test suite or a guarantee of security.

If you approve a fix, restate the accepted finding and invariants. Inspect the new diff and actual test output, then review any changed behavior. Do not treat the original review as covering edits made afterward. A local green check does not prove the production artifact contains the change.

For an independent review, supply the intended behavior and exact code before the patch author's explanation. This gives the reviewer a concrete contract to test rather than an answer to agree with. Use the Claude Code small-fix tutorial if you need a complete regression-test exercise.

Recover when the review is ambiguous

For reviews driven by discussions, use source-linked recording context to preserve the decision and its caveats. Transfer only authorized excerpts, not an entire private meeting or repository credential file.

Try it with Cue

Use your configured shortcut and verify the active mode in Cue Settings. Available app context and actions depend on permissions, version and account. Read the privacy policy before providing confidential material; this guide does not promise all processing stays on your device.

Get Cue for your computer · Current plans

Need help or found an error? Contact Cue support or email eli@sophoninc.com. Include your Cue version, platform, mode and a redacted example. Do not send passwords, tokens or private meeting material.