Codex as an outside advisor to Claude Code: Codex MCP Server and @trishchuk/fetch MCP in practice

Taras Trishchuk · September 2026 | Українська

When Claude Code does most of the work on a project, a single model plans, writes the code and judges its own decisions. The weak point of that setup is self-review: a model that has just proposed a solution may not notice its fundamental flaws. A human reviewer helps, but not at every step.

I address that gap with two MCP servers I built for my own work. Codex MCP Server lets Claude Code get a second opinion through OpenAI Codex — a separate agent powered by another vendor’s model, acting as an outside advisor. @trishchuk/fetch MCP gives the agent access to public web pages that a standard HTTP client sometimes cannot retrieve. Below are scenarios from real projects where each of them helps. Client names and project details have been generalised.

Codex MCP Server: an outside advisor for Claude Code

Codex MCP Server (@trishchuk/codex-mcp-tool on npm, source on GitHub) is an MCP server that gives Claude Code tools for calling Codex CLI. The roles are clearly split: Claude is the implementer, writing code and making decisions within the workflow; Codex is the advisor, reading the project, assessing what has been proposed and returning findings. Claude decides how to proceed, and I retain final oversight.

To keep the advisor an advisor, I run it with sandboxMode: "read-only", which the server passes on to Codex CLI: Codex can read files and run commands but cannot write anything to the project. It therefore cannot silently fix what it was asked to comment on — every finding is visible and can be addressed or rejected. For harder questions I set reasoningEffort: "high" or "xhigh" so that the model performs a more thorough analysis.

Why a different model rather than asking Claude again? Models from different vendors may have different blind spots. A second model with a different perspective is more likely to notice what the author of a solution takes for granted.

Scenarios where a second opinion changes the decision

Checking an algorithm before writing code

In a large product catalogue, some names from one data supplier contained two language variants in a single string. Claude proposed a splitting algorithm that finds the cut point using Jaccard similarity over token sets. Before any code was written, I asked Codex to assess the approach and put several targeted questions to it in order of increasing risk — including which real product names would break the heuristic (bundles such as “×2”, “1+1” promotions, legitimately repeated model numbers) and what safeguard is needed if a split turns out to be wrong.

The advisor’s role: identify edge cases while accommodating them takes one sentence in a specification rather than a data migration.

Reviewing specifications and design documents

For a multi-tenant SaaS platform, Codex received the specification with a direct brief: find the decisions worth revisiting, rather than assess the document as a whole. A design document on making event synchronisation more robust went through several review rounds, including an independent check by another model. In each later round, Codex assessed only the changes made since the previous one, not the whole document again.

The advisor’s role: a critical view of the architecture before it turns into code, and a check of each iteration without repeating the previous one.

A focused check after code review

After reviewing a commit implementing a business rule, one finding was deferred following a risk assessment. The next request to Codex was narrow: are any of the unresolved findings critical?

The advisor’s role: support a ship-or-hold decision instead of running a full review again.

Performance analysis from existing measurements

For a production website, field metrics were already available: mobile LCP was well above the recommended 2.5-second threshold. Codex received the existing measurements and a brief limited to static code analysis — no runtime tracing and no Chrome DevTools MCP, since there was no need to measure again what was already known.

The advisor’s role: find the causes in the code when the symptoms are already known, without spending time on new measurements.

Getting critique from the advisor, not approval

• Ask for critique explicitly. A brief such as “focus on potentially flawed decisions and risks rather than a general assessment” produces far more useful output than “please take a look”.
• Give it specific decisions to assess. A few numbered questions in order of increasing risk work better than a general “what do you think?”.
• Keep the advisor read-only. Review stays separate from changes: findings are visible, and you make the decisions.
• Limit the scope. If the data already exists, say so and rule out unnecessary steps; in later rounds, ask for an assessment of the new changes only.
• Mind what you send. Share only material that may be processed by external models, without secrets or personal data.

@trishchuk/fetch MCP: public web access for the agent

The two tools work at different levels: Codex MCP Server checks decisions, while @trishchuk/fetch MCP gives the agent the sources it needs. The second recurring problem in agent work is access to web pages. Requests from the fetch tools built into agents are often refused where a browser opens the page without difficulty. One reason is that sites classify HTTP clients by network characteristics — a TLS fingerprint (JA3/JA4) and, separately, an HTTP/2 fingerprint — before serving any content.

@trishchuk/fetch MCP sends requests with a browser-compatible TLS and HTTP/2 profile and returns the response to the agent in a model-friendly form. It is built on the @trishchuk/fetch HTTP client (source on GitHub), a native Node.js module written in Rust — whose design was, incidentally, also reviewed by Codex through Codex MCP Server. A browser profile does not guarantee access: the network fingerprint is only one signal among several, alongside IP reputation, headers and client behaviour.

Reading technical documentation

In one practical case, the agent needed the public API documentation of a SaaS service served through Cloudflare. The server retrieved the full page, and the agent worked with the documentation directly instead of relying on manual copying.

The tool’s role: give the agent the primary source rather than a paraphrase or pasted text.

Industry research

In a research project, the agent needed to read dozens of publicly available pages from industry platforms and vendors, as well as public regulatory reports. Consecutive requests to the same domain shared a session, which allows connections and session state to be reused.

The tool’s role: reliably read the series of public sources the research is built on.

Boundaries

@trishchuk/fetch MCP is an HTTP client, not a browser: it does not execute JavaScript, so it cannot pass a Cloudflare challenge page that requires it. When the changelog on one service’s site returned such a challenge (in this case HTTP 403 with the header cf-mitigated: challenge), the attempt ended there, and the agent retrieved the same information from another public source — the API release log. Public availability also does not by itself mean that automated retrieval is permitted: site terms and rate limits still apply.

Which tool for which task

Project pages

• Codex MCP Server — installation and documentation · npm · GitHub
• @trishchuk/fetch MCP — installation and documentation
• @trishchuk/fetch on npm · source on GitHub