Document serving-runtime contracts for exec_command, write_stdin and apply_patch

Type of issue

Documentation / contract clarification.

Scope and relationship to #45309

This separates the tool/process-level follow-up from #45309, which asks how to observe turn completion and the final assistant result. The earlier follow-up is at https://github.com/openai/codex/issues/45309#issuecomment-5674897112.

Here the question is narrower: what supported, version-bound contracts describe exec_command, write_stdin and apply_patch, and the processes and output they manage? A turn-completion event is not being assumed to establish tool-result completeness or descendant-process closure.

I also sent this contract question to OpenAI by email. I am requesting documented guarantees or explicit limitations, not private implementation details or permission to rely on undocumented behaviour.

Questions

1. Serving implementation identity
   Which supported read-only metadata identifies the implementation revision and backend serving these tools in a given Codex environment? A client application version/build does not, by itself, establish that mapping. If these names belong to a hosted or desktop integration rather than the upstream CLI, please identify the supported interface or owning component.

2. Native results, errors, asynchronous sequences and output retention
   At that revision, where is the specification for the complete tool-result and error shapes, asynchronous continuation ordering, record/session identity, and retention semantics? How should a consumer distinguish the entire value delivered by a tool from complete underlying stdout/stderr? Please identify any truncation, omission, encoding conversion, buffering or retention limitations, and the supported consumer interface.

3. Parent, descendant and stream-writer ownership
   What supported producer, if any, supplies verifiable parent-dispatch, descendant and stream-writer ownership records, and how are those records joined to the actual invocation and consumed? A session handle alone is not being assumed to be an OS process identity or containment proof.

4. Cancellation, reaping and terminal evidence
   Which observable terminal, if any, establishes cancellation/reaping and output closure for all owned descendants and writers? Please distinguish the directly launched process exiting, its output closing, and all-descendant containment/closure. What is documented about cancellation acknowledgement, bounded completion and terminal evidence when a request fails or is interrupted?

Public sources consulted

• Tool result representations and serializers
• Unified exec process manager
• Unified exec process lifecycle
• Exec-server protocol

These mutable main links are investigation pointers, not proof that the same code serves my connected runtime. Likewise, documented app-server commands are not being assumed interchangeable with the three tool names above.

Useful resolution

Versioned documentation/schema/source references, together with their applicability to the serving runtime, would answer this request. If any requested guarantee is unsupported or unavailable through a supported interface, saying so explicitly is equally useful. If this belongs outside openai/codex, please identify the appropriate component or support channel.

No credentials, private history or an evidence-policy exception are requested.

Start with codex-rs/core/src/tools/context.rs, codex-rs/core/src/unified_exec/process_manager.rs, codex-rs/core/src/unified_exec/process.rs, and codex-rs/exec-server/README.md. Compare their documented schemas and lifecycle behavior, then determine whether they apply to the serving runtime described here. Done means adding versioned documentation or source references for the requested contracts, or explicitly recording unsupported guarantees and the appropriate owning component.