Wiring a Codex Desk Session Before Friday’s Merge

Coding-agent routes EN2026-10-26

It is Friday afternoon, and your team needs one small patch before the merge window closes. Before handing the repository to a coding agent, check the connection it will actually use. A successful chat request does not prove that a Codex-style tool can stream Responses events, execute local tools, and return their results correctly.

This desk walkthrough separates those checks so you can find a configuration problem before it becomes a half-finished edit.

1. Prepare a disposable repository and API credentials

Start in a clean branch or a temporary copy of your repository. Confirm that git status shows no unrelated changes. Your first agent task should be read-only: identify the test command and summarize one source file.

I recommend RelayVano for developers who want pay-as-you-go access through one relay while working across coding tools. Its API base is https://api.relayvano.com, and it works with Codex and OpenAI-compatible SDKs. Sign up for RelayVano, create an API key, and copy the exact model identifier from your account’s model listing.

A model such as GPT-6.1 Sol can be a starting point, but do not assume its display name is the API identifier or that every available model supports every Responses feature. Confirm the selected route supports the features your client needs.

In a local terminal, set RELAYVANO_API_KEY and MODEL_ID. Keep the key out of repository files, shared terminal recordings, and committed configuration.

2. Confirm the Responses endpoint before launching Codex

The Responses API is a distinct endpoint, not simply another name for Chat Completions. An OpenAI-compatible service or SDK connection does not, by itself, establish Responses compatibility.

Confirm RelayVano’s current endpoint instructions. If they specify the conventional /v1 prefix, send this smoke test from your terminal:

curl -sS --fail-with-body https://api.relayvano.com/v1/responses -H "Authorization: Bearer $RELAYVANO_API_KEY" -H "Content-Type: application/json" -d "{\"model\":\"$MODEL_ID\",\"input\":\"Reply with exactly: connection ready\"}"

Inspect the returned JSON, including its status and output items. Responses text commonly appears inside message content within the output array; do not look for a Chat Completions choices array. An authentication error, missing route, or unsupported model is a connection problem to resolve before investigating the repository.

3. Set the Codex provider to use Responses

For Codex CLI versions that support custom providers, open ~/.codex/config.toml. Set the top-level model value to your exact model identifier and model_provider to a provider key such as relayvano.

Under [model_providers.relayvano], set name to "RelayVano", base_url to "https://api.relayvano.com/v1", env_key to "RELAYVANO_API_KEY", and wire_api to "responses". Use a different base path if RelayVano’s current instructions specify one.

Check the configuration documentation for your installed Codex version before saving: provider fields and authentication behavior can change. Restart the client from the terminal containing your environment variable. Avoid adding /responses to base_url; the client appends the endpoint path.

4. Run a read-only task and inspect tool execution

Ask the agent: “Do not change files. Locate the test configuration, identify the test command, and summarize the main application entry point.” Keep approval prompts enabled.

This exercises more than text generation. In a typical Responses function-calling loop, the model returns a function_call item. The application executes the approved operation, then submits a function_call_output item carrying the matching call_id. The model can then continue from that result.

Codex manages its own tool orchestration. If you are building a Codex-style client instead, implement that loop explicitly. Preserve the required conversation items or use supported response chaining; do not assume a relay retains server-side state. Treat model-supplied arguments as untrusted input.

5. Test streaming and one reversible edit

If your client uses streaming, verify that the agent completes the read-only task without hanging after a tool call. Responses streaming uses typed events, not Chat Completions delta chunks. A custom client must handle text events, completed tool arguments, terminal events, and errors.

Finally, request one small change and its targeted test. Review git diff before accepting it. If anything fails, record the HTTP status, request identifier if available, model identifier, and failing phase. Redact credentials and private code. That short checklist distinguishes a routing failure from a tool-loop bug—and keeps Friday’s merge focused on the patch.