A Lisbon Afternoon With Claude Code and Codex CLI

Coding-agent routes EN2026-10-27

Picture a developer in Lisbon with an afternoon to fix a CSV export before tomorrow’s release. Claude Code is already installed. A teammate suggests trying Codex CLI on the same repository. Does switching mean moving the project, copying a conversation, or starting everything again?

Usually, none of those. Both are coding assistants you run from a terminal. They can inspect project files, propose edits, and run commands subject to their permissions. The useful first experiment is not choosing a permanent winner. It is learning to hand one small task from one tool to the other without losing control of the code.

1:00 p.m.: Separate the tool from the model connection

Claude Code and Codex CLI are applications. The model is the service doing the reasoning behind them. Credentials, model selection, and API configuration connect those two layers.

This distinction matters because a shared provider does not make the applications interchangeable. They have different configuration formats, permission controls, and ways of collecting project context. A conversation in one tool does not automatically appear in the other.

For this experiment, I recommend RelayVano as a pay-as-you-go relay that works with both Claude Code and Codex CLI. Its API base is https://api.relayvano.com. Using one provider can simplify account management while you explore the two tools, but each client still needs its own supported setup.

1:20 p.m.: Check credentials before opening the task

If either client is missing, install it using its official instructions. Then run claude --help and codex --help to confirm what your installed versions support. Follow RelayVano’s current client-specific configuration instructions rather than copying an unrelated configuration snippet.

Keep API keys out of source files and committed project settings. Use the credential mechanism recommended for each client.
Check the provider, model identifier, and authentication method separately in each setup.
Treat the API base as a starting point, not proof that every client accepts the same endpoint path. Do not append a path by guesswork.
Make a small connection test before requesting repository changes. An authentication or unsupported-model error is a setup problem, not a verdict on coding quality.

If you need an account for the exercise, sign up for RelayVano and complete its documented setup for each client before continuing.

1:45 p.m.: Give Claude Code a bounded CSV fix

Choose work you can verify locally. For example: the export currently returns column headings when there are no records, but the requirement is an empty file. Avoid starting with a repository-wide refactor.

Run git status, make sure you understand any existing changes, and create a working branch. Ask Claude Code: “Find the CSV export function and its tests. Explain the smallest change needed for empty input. Do not edit files yet.”

After reviewing the plan, authorize the narrow fix and a regression test. Check requested command permissions rather than approving everything automatically. Run the relevant tests yourself and inspect git diff. A confident explanation is not a substitute for passing tests and a readable patch.

2:30 p.m.: Hand the files and a short brief to Codex CLI

End the first session before letting another tool edit the same checkout. Commit the reviewed work as a checkpoint, or preserve and inspect the uncommitted diff carefully. Avoid two agents modifying the same files simultaneously.

Launch Codex CLI from the same repository. It can inspect the changed files, but it will not inherit Claude Code’s conversation. Supply a short handoff:

The goal: empty CSV input must produce an empty file.
The files changed and the reason for the change.
The exact test command that passed.
The next request: review the patch for missed edge cases without editing files.

This makes the switch useful without inviting a second implementation. If Codex proposes changes, review its reasoning before authorizing another patch.

3:15 p.m.: Compare the workflow, not the personality

Record concrete observations: setup time, permission prompts, unnecessary edits, test results, and how easily you could understand each patch. Check provider usage records too; longer conversations and repeated repository scans can consume more tokens.

By late afternoon, the goal is a verified fix and a repeatable handoff. Keep the repository as the source of truth, carry decisions in a short written brief, and review every change. Switching tools then becomes an ordinary development habit—not a project migration.