How to manage test cases with Codex and MCP

Q: Does Codex support remote MCP servers over HTTP?

Yes. A [mcp_servers. ] table with a url connects over Streamable HTTP; codex mcp get shows the transport as streamable_http. Headers such as Authorization go in http_headers.

Q: Why did codex exec not call the MCP tool?

In codex exec, a tool call that needs approval fails when the approval policy is never. Set default_tools_approval_mode = "approve" on the server, ideally together with an enabled_tools list, so only the tools you chose run without asking.

Q: Can Codex create test cases in TestOrchestrator?

Yes. In our run Codex called create_test_case with the project, folder, title and the id of the Draft state, and then read the case back with get_test_case. The case appeared in the app as C-2, state Draft.

Q: Is the key safe in config.toml?

It is as safe as the file. The key acts as you, so keep config.toml out of repositories and shared folders, give the key an expiry, and revoke it in Settings → API keys when you stop using it.

01What you need

Codex CLI. We used codex-cli 0.166.0, signed in with a ChatGPT account.
A TestOrchestrator personal key. Create it under Settings → API keys → New key; it is shown once and expires after 90 days unless you choose otherwise. Every plan has the MCP server, Free included.
A project with a folder, so Codex has somewhere to put the new case.

021. Add the server to config.toml

Add this to ~/.codex/config.toml, with your key in place of the placeholder:

[mcp_servers.testorchestrator]
type = "http"
url = "https://api.testorchestrator.com/mcp"
enabled_tools = ["get_projects", "get_test_cases", "get_test_case", "get_folders", "get_lifecycles", "create_test_case"]
default_tools_approval_mode = "approve"

[mcp_servers.testorchestrator.http_headers]
Authorization = "Bearer to_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

The first block is the one in the MCP docs. The two extra lines are what made the non-interactive run work:

enabled_tools limits Codex to the tools this job needs. The server offers 39; leave the line out to expose all of them.
default_tools_approval_mode = "approve" lets those tools run without a prompt. Without it, codex exec stopped at the first tool call: with the approval policy set to never, a call that needs approval fails instead of asking. In an interactive session you can leave it out and approve each call instead.

For a one-off run you can pass the same keys on the command line as -c key=value overrides; that is how we ran the session below, without touching the saved config.

032. Check that Codex sees the server

codex mcp list

Name              Url                                   Bearer Token Env Var  Status   Auth
testorchestrator  https://api.testorchestrator.com/mcp  -                     enabled  Bearer token

codex mcp get testorchestrator shows transport: streamable_http and masks the header as Authorization=*****.

043. The round trip, tool by tool

We gave codex exec one instruction: list my projects; in the Checkout project read test case 1; create a case in the Payments folder titled "Refund to an expired card goes to store credit" in the Draft state, looking the state up with get_lifecycles; read it back.

#	Tool Codex called	Arguments	What came back
1	`get_projects`	none	One project, Checkout, id 1
2	`get_test_cases`	`project: 1`	One case, C-1 "Pay with a saved card", state Ready
3	`get_test_case`	`project: 1, caseId: 1`	The full case: folder, template, state, fields
4	`get_folders`	`project: 1`	The Payments folder, id 1
5	`get_lifecycles`	`project: 1, context: REPOSITORY`	The case states, with Draft as id 1
6	`create_test_case`	`project: 1, folder: 1, title: …, lifecycleStateId: 1`	The new case, number 2
7	`get_test_case`	`project: 1, caseId: 2`	The same case, read back

Codex finished with: "Created and verified: ID: 2, Case number: 2, Title: 'Refund to an expired card goes to store credit', Folder: Payments (ID 1), Lifecycle: Draft (ID 1)." In the app the case list showed C-2 in the Payments folder with state Draft, next to C-1 in Ready.

Two things the run shows. Codex looked up the folder and state ids before writing, because the tools take ids, not names. And the new case is in Draft only because the instruction asked for it: in a new workspace the default state is Ready.

054. Tell Codex how your team works

Put the rules in the instruction, or in your repository's AGENTS.md so every Codex session reads them:

Create every new case in Draft; a person moves it on after review.
Use the project's template: call get_fields and fill the steps and priority it defines.
Link each case to the issue it covers with link_to_issue.
Never close a test run; leave that to a person.

065. Revoke the key when you are done

Every call Codex makes runs as you: the cases it creates are recorded under your account. When you stop using the setup, revoke the key in Settings → API keys. We did, and the next request with that key was refused with HTTP 401.

08Frequently asked questions

Does Codex support remote MCP servers over HTTP?

Yes. A [mcp_servers.<name>] table with a url connects over Streamable HTTP; codex mcp get shows the transport as streamable_http. Headers such as Authorization go in http_headers.

Why did codex exec not call the MCP tool?

In codex exec, a tool call that needs approval fails when the approval policy is never. Set default_tools_approval_mode = "approve" on the server, ideally together with an enabled_tools list, so only the tools you chose run without asking.

Can Codex create test cases in TestOrchestrator?

Yes. In our run Codex called create_test_case with the project, folder, title and the id of the Draft state, and then read the case back with get_test_case. The case appeared in the app as C-2, state Draft.

Is the key safe in config.toml?

It is as safe as the file. The key acts as you, so keep config.toml out of repositories and shared folders, give the key an expiry, and revoke it in Settings → API keys when you stop using it.