How We Use Claude Code and Codex to Review Client Software

A second review before client software ships

A useful way to combine Claude Code and Codex is to give one assistant a bounded implementation task and ask the other for an independent review of the same source and requirements. At Rhize, this sits inside a broader delivery process: a clear brief, tests, review, an authorized release and a check of the running result. The tools support that process; they do not make production changes automatically safe.

Two agents, deliberate roles

The implementation role reads the repository instructions and acceptance criteria, makes the scoped change and records its checks. More demanding architecture or security work needs an appropriately capable reviewer. The selected model and host can vary; the contract is about the work and evidence, not a permanent model ranking.

The current cross-model-handoff skill can request a review or bounded file proposal through the shared bridge in either direction between Claude and Codex. It requires the documented native subscription logins and MCP setup. The remote worker has no tools, so the coordinator must supply enough source context and then inspect, test and integrate its proposal. It is not an automatic requirement to send every task to another provider.

None of this is a claim that one model writes better code than the other. It is model diversity built into the review process, nothing more.

Two agents means two independent reads on a plan before code ships, not a contest over which one is smarter.

Nobody grades their own work

A separate reviewer can check a change against the requirements, diff and test evidence. That independent perspective can find omissions, but it is not proof that a change is correct. The coordinator must resolve actionable findings, rerun affected checks and keep release authority with the person or policy responsible for that repository.

Each repository carries its own STATE.md, a running record of verified facts, open failures, and lessons learned from earlier sessions. A fresh session, whether started by a person or another agent, reads that file before touching code rather than re-deriving context from scratch.

Independent review adds another opportunity to find an error; tests and production checks still need to pass.

Guardrails that run no matter which model is driving

Guardrails have to match the host and operation. File-edit hooks, shell restrictions, static analysis and repository tests cover different paths. Inspect what is enforced in the actual session, especially when a command can write files outside the editor tool. A named rule is not evidence that every tool path enforces it.

Credentials should remain in an approved secret store and be supplied only to the process that needs them. Our bundled MCP secret launcher supports reading named Keychain items into a child process environment. That is scoped environment delivery, not a claim that secrets never enter an environment. Missing credentials should produce a clear failure without printing their values.

Never accept a proxy's summary as proof that a correctness gate passed. Re-run it unwrapped when the exact output matters.

Signatures and explicit approval

A commit signature can help verify the identity and integrity of a recorded change. It is distinct from approving a deployment or allowing a workflow to execute. Configure signing according to the repository's requirements and verify the resulting commit rather than assuming a configured option proves a signature exists.

The procedural-memory registry uses content digests, trust, health and approval boundaries around executable artifacts. A recorded approval must refer to the intended version. A changed artifact does not inherit authority merely because its filename stayed the same.

Use the repository's current approval contract. Some operations require a person to approve the exact proposed action; others may fall within previously authorized automation. Keep the evidence of that authority separate from test results and commit metadata.

A signed commit, a passing test and an authorized release answer different questions.

Push policy sized to blast radius

Read the repository's push and release policy before changing it. Internal tooling and a production client application can have different rules. Prepare the concrete diff, test evidence and deployment plan before the release decision, then act only within the authority already established for that repository.

Two habits back this up. Commits are confirmed by inspecting the resulting commit, not by trusting a zero exit code, since a hook can fail in ways an exit code will not show. And when another session might be working in the same repository, files are staged by explicit path rather than added wholesale.

Scope and release authority determine which actions may proceed. A successful build does not grant permission to deploy.

Where the code runs: Vercel and Sentry

Vercel can provide preview deployments for a change before production. Use them to test the affected routes and user flows, but inspect environment variables, access controls and data sources before calling a preview equivalent to production. After release, verify the actual production route and version.

Sentry and deployment logs can help identify failures in the running system. Start a bug investigation with the relevant event, environment and release, then connect the fix to that evidence. An automated root-cause suggestion still needs checking against the code and observed behavior.

Where client content and records live: Sanity, GoHighLevel and Salesforce

For Sanity content, read the schema and current document before editing. Bind the intended change to the version you reviewed and inspect the published result after authorized publication. Saving a draft is different from making it public.

CRM work splits by client type. For home-service and local-business clients we wrap GoHighLevel rather than replace it, and social posts get staged as unscheduled drafts that wait for human approval before anything goes out. For at least one B2B client, the CRM is Salesforce, developed as a standard Salesforce DX project with flows, Apex, and objects, built and deployed through the sf CLI.

Automation and infrastructure changes

Self-hosted n8n is one way to run integrations and scheduled workflows. It moves responsibility for hosting, updates, access and failure recovery to the operator. The lack of a SaaS per-execution charge does not make the workflow free or remove model and infrastructure costs.

For infrastructure work, use a supported control-plane API or CLI and confirm its permissions. An unavailable SSH route should be diagnosed, not treated as permission to bypass network controls.

Supabase provides managed Postgres and supported tools for schema and application work. Review migrations against the intended environment, test them appropriately and keep production database writes behind the applicable authorization.

The stack map, and the languages and tools behind it

Pulling the tour together into one reference:

Choose languages and runtimes already used by the project. Pin the supported versions and dependencies, and record enough setup information that another session can run the same checks. A stack inventory is useful only when it reflects the repository being changed.

Prefer a supported API, SDK or CLI for a structured operation. Inspect permissions with a harmless read where possible, and distinguish lack of access from an unsupported feature. Keep secrets and private customer material out of diagnostic output.

What we publish back: the open-source Rhize plugins and skill-forge

We publish a set of tools publicly at rhize.media/ai-tools and through the rhize-plugins marketplace, the same guardrails described in this article, available for anyone to try. rhize-devflow runs plan, build, test, and independent review for production Next.js, Sanity, and Vercel apps, including a refactor-evidence gate that requires an impact map before a structural change ships. rhize-context-manager keeps memory and working context organized across long agent sessions. rhize-ops hands work to teammates with full context attached and tracks which skills earn their keep over time. procedural-memory is a registry of verified, digest-bound scripts and workflow graphs that agents re-run instead of recomposing from scratch each time.

skill-forge provides a separate review path for third-party agent skills. Use its documented checks to inspect what a skill can do before installation. A clean scan is one input to review, not a guarantee that every later instruction or dependency is safe.

The loop, start to finish

The workflow is: state the acceptance criteria; inspect the relevant source; implement in a scoped branch; ask for an independent review where warranted; resolve findings; run the required checks; obtain or confirm release authority; deploy through the supported path; verify the running result. If the second reviewer has no tools, supply source snapshots and compare its proposal with the current files before integration.

That last point is close to our public position on all of this: we wrap what a client already has rather than ripping it out, and we design the system around AI from the first sketch instead of bolting it on afterward.

Each check has a specific job. Record what it proves and what remains untested instead of combining several partial signals into a blanket success claim.

Apply the workflow to a bounded change

For a website form repair, the acceptance criteria might cover input validation, successful submission, error handling and the destination record. The implementation assistant changes the relevant code. The reviewer checks the diff and failure paths. A person or authorized release process decides when to deploy, and the coordinator verifies the public form afterward.

For a CRM or content change, the same pattern applies to records rather than code: read the current schema and values, prepare the exact proposed mutation, verify authorization and inspect the resulting record. Do not count a model's completion message as delivery evidence.

Frequently asked questions

Is Claude Code or Codex better?

Neither, and that is not the point of running both. We use the two for model diversity in review, an independent second read before a non-trivial plan ships, not a verdict on which model writes better code.

What stops an agent from pushing broken code to production?

Scoped permissions, relevant tests, independent review, release authorization and post-release verification reduce different risks. None guarantees that broken code can never reach production; retain monitoring and a rollback plan.

Are all of your commits signed?

Signing is configured per repository. Inspect the actual commit and the applicable policy rather than assuming every project uses the same signing arrangement.

Can a business without an engineering team use any of this?

Yes, in two ways: through the open-source Rhize plugins at rhize.media/ai-tools, or by working with Rhize directly to build client software on this stack.

Start with one change where the acceptance criteria and release boundary are clear. The Rhize Plugins marketplace contains the review and handoff workflows described here. For help designing a delivery process around your existing systems, book a 30-minute call at /book to discuss the problem and next step.