Skip to main content
Glama
jgt87
by jgt87

Hand Codex a plan to execute

codex_execute_plan

Execute a concrete step-by-step plan in the background, returning a job ID for tracking, while Codex follows the plan faithfully without redesigning.

Instructions

The execute half of plan→execute: you do the design thinking in this conversation, write a concrete step-by-step plan, and hand it here for Codex to carry out in the background — getting a jobId back immediately, exactly like codex_start. Codex is told the plan was authored by another model and to follow it faithfully rather than redesign: if a step is wrong or impossible it stops and reports in blockers instead of improvising, so you can revise and resume with codex_reply. Reach for this when the hard part was deciding what to do and the rest is faithful typing across files — it keeps the reasoning on your side and the output tokens on Codex's. Because the design is already done, the execution usually needs less reasoning effort than the planning did, so consider pinning a lower reasoningEffort unless individual steps are themselves subtle. The plan must be self-contained: Codex cannot see this conversation, so state every step, file, and acceptance check in the plan text itself. Keep working while it runs; check codex_status when you need to and collect the result with codex_result, which checks what Codex did against git — don't re-check in a tight loop, since each check is a model turn.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdYesAbsolute path to the directory Codex should treat as its working root.
planYesThe step-by-step plan for Codex to execute. Write it as an ordered list of concrete steps naming the files to touch and what each change is, plus how to tell it worked (tests to run, behaviour to check). Self-contained: Codex cannot see this conversation.
modelNoPin the model instead of letting it be chosen from the plan. Available: (model index unavailable; Codex config defaults apply). Omit to let routing pick one.
addDirsNoExtra absolute directories Codex may write to, beyond cwd.
sandboxNoread-only = cannot modify anything; workspace-write (default) = may edit files under cwd; danger-full-access = unrestricted, avoid unless the caller explicitly asked for it.
autoRouteNoDefault true. Set false to use only the values you pass (or Codex defaults).
structuredNoDefault true: Codex returns a typed handoff report. Set false only for long prose where the structure would get in the way.
documentationNoDefault true for jobs that can write: Codex updates existing docs the change makes untrue and reports what it touched. Set false to suppress. Always off under read-only.
reasoningEffortNoHow hard Codex should think while executing. The planning is already done, so mechanical execution can take a lower setting than the task as a whole would — raise it only when individual steps are themselves subtle. Omit to let routing choose from the plan text.
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description handles the burden well. It explains that Codex follows faithfully, stops on blockers, and cannot see the conversation. It mentions returning a jobId immediately and working in background. However, it could explicitly mention that the tool modifies files based on sandbox settings, though that is covered in parameter descriptions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph that front-loads the core purpose and then provides detailed usage guidance. While not overly verbose, it could be slightly more concise (e.g., 'the execute half of plan→execute' is a bit redundant). Still, every sentence contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description mentions returning a jobId but doesn't fully specify the return format or structure. However, for a tool with 9 parameters and complex behavior, it covers the essential aspects: execution model, blocking behavior, plan requirements, and post-execution flow via codex_result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant context beyond the schema: for 'plan' it stresses self-containment and structure, for 'reasoningEffort' it gives nuanced guidance on when to lower it, and for 'sandbox' it explains defaults and warnings. This extra information helps the agent choose appropriate values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies this as the execution half of a plan-execute split, with specific verb 'hand' and resource 'plan'. It distinguishes itself from codex_start by emphasizing the pre-planned nature and from other siblings like codex_status and codex_result by stating it returns a jobId immediately and is for background execution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: 'Reach for this when the hard part was deciding what to do and the rest is faithful typing across files.' It provides guidance on when not to use it implicitly, mentions alternatives like codex_reply for blockers, and gives tips on reasoningEffort and plan self-containment.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jgt87/codex-offload-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server