Skip to main content
Glama
quolu
by quolu

codex_agent

Launch a persistent Codex agent for coding implementation, review, or investigation. Send a prompt and continue; the agent runs asynchronously with configurable model and reasoning effort.

Instructions

【Codex (OpenAI)】の対話エージェント TUI を永続端末に起動する。実装・レビュー・調査を対話で回す。通常CLIと同じHOME・cwd・project/user/local設定・MCP・plugin・skill・permission/trustを共有する。aitermは完了相関stateだけをlaunch単位で所有する。起動されたagentにはsub-agent自己認識、親session、delegation depth/lineage、delegation_allowed=trueを注入し、必要な追加委譲は許可する。委譲契約を使う完全な呼び出し例: codex_agent({"prompt":"<依頼>","model":"gpt-5.6-sol","reasoning_effort":"high","cwd":"/absolute/path/to/repo","write_scope":"read-only"})。turn は pty_send で送る(自動で非ブロック dispatch になる)。起動して投げたら投げっぱなしでよい=親はここで待たない。完了通知は起動応答の wait_command(初回prompt時)または pty_send dispatch 後の aiterm-wait --session --cursor を親のターンを塞がない別プロセスとして起動して受ける(exit 0=done / 3=timeout(既定600秒・未完了) / 4=closed。receiptのoutcomeが正で、done以外は未完了。ポーリング不要・foreground実行はしない)。結果回収は pty_read(agent_transcript:true)。model / reasoning_effort を引数で指定可(省略時は端末 config/CLI 既定を継承。実効値は起動応答に明示)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNo作業ディレクトリ(対象リポのルート等・任意)
modelNo起動モデル(例: gpt-5.6-sol / gpt-5.6-terra / gpt-5.6-luna)。省略時は端末 config/CLI 既定を継承(端末側のピンがそのまま効く。実効値は起動応答に明示される)
promptNo起動時に渡す初手プロンプト(任意)。送信後は待たずに即返る
write_scopeNo能力宣言。read-only、または書込みを許可するパスの説明文字列。Codexのread-onlyだけはCLI sandboxで実効禁止する
session_nameNoセッション名(省略で自動採番)
reasoning_effortNoreasoning effort(思考レベル)。low/medium/high/xhigh/max/ultra(CLI 版依存)。ultra は max 推論+proactive 自動委譲 ON=使用量急増注意(明示要求時のみ)。省略時は端末 config/CLI 既定。
throughline_source_sessionNo同一端末のThroughline sessionから所有権を変えずに記憶を読み、promptのmissionより前へ注入する

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
schemaYes
providerYes
session_idYes
write_scopeNo
event_cursorYes
wait_commandYes
submit_residueYes
managed_completionYes後方互換field。trueはaiterm完了相関が有効という意味で、project/user環境の隔離を意味しない
write_scope_enforcementNo
Behavior5/5

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

With no annotations provided, the description carries the full burden. It discloses non-blocking behavior, state ownership (aiterm owns completion state per launch), configuration sharing, delegation injection (self-awareness, parent session, delegation_allowed=true), completion signaling with exit codes, and result retrieval via pty_read. It even notes that effective model/reasoning_effort values appear in the launch response. This is a thorough behavioral contract.

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 dense and front-loaded with purpose, then flows into operational details. It is longer than average but every section serves a purpose. There is some redundancy (e.g., 'don't wait' appears multiple times), but overall it is efficiently structured for the tool's complexity.

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

Completeness5/5

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

Given the tool's high complexity (async agent launch, delegation, completion waiting, result retrieval), the description is remarkably complete. It supplies a call example, wait/exit protocol, result retrieval method, parameter defaults, and inheritance behavior. The presence of an output schema covers return structure, so the description does not need to explain that.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds a complete invocation example and clarifies parameter inheritance (model/reasoning_effort fallback to terminal config/CLI defaults, effective value in response). However, most parameter semantics are already well-captured in the schema, so the incremental value is modest.

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 opens with a specific verb and resource: launching the Codex (OpenAI) interactive agent TUI in a persistent terminal, with explicit use cases (implementation/review/investigation). This clearly distinguishes it from sibling agent tools (claude_agent, grok_agent, composer_agent) and from low-level terminal tools (pty_open, pty_send).

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 provides explicit operational guidance: send turns via pty_send, do not wait or poll, use aiterm-wait with specific exit codes (0/3/4), and retrieve results via pty_read. It states 'launch and leave' and 'no foreground execution', giving clear when-to-use and when-not-to-use boundaries. While it doesn't explicitly contrast with other agent launchers, it defines a complete workflow and names alternative tools for each step.

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/quolu/aiterm-mcp'

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