List all Codex subagent tasks in the current session and inspect running progress, changed files, output previews, or full results for specific task IDs.
立即返回，不等待。不传 ids：一行一个列出本会话全部任务及状态。传 ids：看详情——运行中的显示最近动作、改动文件、输出预览；已结束的显示完整结果（超过 6000 字截断，full=true 看全文）。被 codex_interrupt 中断的任务，其已产出的部分也从这里取。
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | 任务 id 列表；省略 = 只列清单 | |
| full | No | true = 不截断，返回完整结果文本 |
Changes observed during successful MCP inspections.
v0.2.3Input schema / properties / full / descriptionAdded value: +"true = 不截断，返回完整结果文本"Input schema / properties / ids / descriptionAdded value: +"任务 id 列表；省略 = 只列清单"v0.2.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety profile is covered. The description adds valuable behavioral context: immediate return (no waiting), truncation at 6000 characters, full=true to see entire text, and that partial output from interrupted tasks is retrievable. This goes beyond annotations and helps an agent predict output size and completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the immediate-return behavior. Sentences are dense but each conveys necessary behavior (listing vs details, truncation, interrupted tasks). Slightly heavy but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only status tool with no output schema, the description covers the key behavioral aspects: return timing, output structure with/without ids, truncation limit, and partial results from interrupted tasks. It does not explain pagination or exact format of the listing, but given no output schema, the coverage is good enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (ids, full) are fully documented in the schema. The description mirrors the schema semantics (e.g., full=true for untruncated) but adds no syntax or format detail beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool reports status of tasks and details, with explicit behavior for with/without ids. However, its difference from siblings like codex_wait or codex_interrupt is only implicit — an agent might confuse status-checking with waiting. It mentions codex_interrupt, but no direct differentiation from the other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says when to omit ids (list all) vs provide ids (detail view). It does not explicitly tell when to use this tool versus codex_wait or codex_interrupt, nor does it exclude cases. Implied usage only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.