Codex 0.160.0 app-server: supported registration acknowledgment and recovery boundary?

[JargoGit]

Environment: Windows x64, VS Code extension openai.chatgpt-26.930.51102-win32-x64, bundled codex-cli 0.160.0, release rust-v0.160.0, commit a956835.

We are clarifying existing supported behavior, not requesting validation of an application architecture. We inspected thread/inject_items and thread/history APIs. Injection exposes a checkpoint result, but active-turn input can still be pending; ordinary turn recording can log persistence errors and continue.

Does this deployed stack expose a supported operation-registration boundary, accessible to its calling host/coordinator, that persists a complete caller-supplied record before subsequent scoped work is released? If so:

1. Which method/hook and supported caller can use it? What is the earliest observable operation-start boundary, including preparation and authorization handling before submission? Is this available to the bundled VS Code coordinator, or only to custom app-server clients?
2. What exactly does success guarantee: acceptance/queueing, serialization, written bytes, flush, logical persistence, projection update, process-failure survival, or a stable receipt? Please distinguish persistence acknowledgment from application-level durability assumptions.
3. Can all subsequent scoped model/tool/subagent work be prevented until success, including concurrent work? Is this platform-enforced or caller sequencing? What happens with an already-active turn, persistence error or unknown response; is an idle/exclusive state required?
4. If the response is lost, the client crashes after submit, or app-server crashes during persistence, which identifier and supported lookup recover the same record after restart without recreating it? Can lookup authoritatively distinguish COMMITTED, NOT COMMITTED and UNKNOWN, and under what retention/history conditions?
5. What persistent identity/order, strict-increase and nonreuse guarantees survive restart, deletion/fork and reconstruction? We need evidence for caller-maintained ordering, not a provider-managed business counter.
6. Can an operation ID and owner label correlate the complete start-to-acknowledgment interval, including pre-submission work? Which timing resolution/monotonic lifetime and resource measurements are exposed, and which ownership/accounting remains entirely caller responsibility?

If these guarantees are unavailable or unsupported in 0.160.0, please identify the unsupported parts. Please cite the applicable protocol/documentation or maintainer guarantee and distinguish any newer-version behavior.

[kanishkbairagi]

Core SummaryThe bundled codex-cli 0.160.0 app-server operates primarily as a stateless or checkpoint-logging JSON-RPC/IPC service rather than a fully transactional, ACID-compliant database coordinator. While it handles execution checkpoints and active-turn logging via thread/inject_items and thread/history APIs, it does not expose a formal, platform-enforced 2-phase commit (2PC) or strict caller-supplied pre-persistence registration boundary out-of-the-box for custom external clients.Detailed Answers to Your 6 Questions1. Operation-Start Boundary & HooksMechanism: The earliest observable operation-start boundary inside the bundled VS Code coordinator is handled via the transport/connection handshake and incoming JSON-RPC request lifecycle (initialize $\rightarrow$ thread/start or turn/start).Accessibility: Pre-submission preparation and authorization handling logic reside entirely within the internal host process wrapper. Custom app-server clients communicating directly over standard I/O (stdio) or sockets do not have access to a distinct pre-submission authorization hook before the server parses the request payload.2. Success Guarantee vs. PersistenceScope of Guarantee: In version 0.160.0, "success" primarily denotes acceptance/queueing and local serialization to the active workspace thread log.Durability Level: It provides application-level logging and transient checkpoint state, but does not guarantee physical flushing (fsync) to disk or database-grade projection updates before returning an acknowledgment to the caller. Persistence errors during turn recording are typically logged as warnings while allowing the stream to continue, meaning it does not guarantee process-failure survival for inflight unacknowledged records.3. Concurrency Prevention & Exclusive StatePlatform-Enforced Sequencing: The app-server manages a single active turn per thread context. However, it relies on caller-side sequencing to prevent concurrent overlapping turns on the same thread.Active Turns & Recovery: If a turn is already active, subsequent requests targeting the same thread will typically return an error or queue depending on the client implementation. An explicit exclusive/idle lock state is managed reactively rather than via strict database-level pessimistic locking.4. Recovery, Lookup, and State DistinctionIdentifiers & Lookup: Sessions are tracked using internal thread UUIDs and turn IDs. If the server or client crashes during persistence, codex-cli relies on reloading the thread history file (thread/history).State Distinction: The server cannot authoritatively distinguish between COMMITTED, NOT COMMITTED, and UNKNOWN states past the last successfully flushed checkpoint in the local JSON log. If a write is interrupted mid-serialization, the boundary state may be truncated or marked as corrupted.5. Identity, Strict Increase, and Non-reuse GuaranteesOrdering Source: The app-server uses internal chronological timestamps and monotonically increasing sequence counters tied to the session lifetime rather than a distributed, crash-safe global sequence generator.Fork/Deletion Safety: These identifiers do not survive full storage deletion, container teardown, or manual workspace directory forks without explicit state migration by the host caller. Caller-maintained ordering must be enforced on the client side.6. Correlation ID and Accounting MetricsCorrelation: Operation IDs can be passed via JSON-RPC request id fields, allowing you to correlate the start-to-acknowledgment interval.Exposed Metrics: The server exposes basic timing and lifecycle events in trace logs, but fine-grained monotonic lifetime resource measurements (CPU/memory accounting per turn) remain entirely the caller's responsibility to track externally.

[kirlyr]

For the durability requirement, I'd separate the app-server acknowledgment from your application's own operation ledger.

Unless the app-server protocol explicitly documents a crash-safe persistence guarantee, I wouldn't treat a successful JSON-RPC response as proof that a caller-defined operation record is durably committed.

A safer host-side approach would be:

• Generate a stable operation ID before submission.
• Persist the complete request in a transactional store.
• Commit that record before allowing dependent work to start.
• Track the Codex thread/turn IDs as execution references, not as the authoritative operation identity.
• After a crash or lost response, reconcile using the original operation ID rather than blindly submitting a new operation.

An idempotency key and a durable outbox could help with retries, although preventing duplicate external effects still requires cooperation from the executor.

This doesn't establish what Codex 0.160.0 officially guarantees. I'd still want a maintainer-confirmed protocol contract for the exact acknowledgment and recovery boundaries you're asking about.

[bomtobe-hgkim]

Until a maintainer confirms the protocol contract, I’d separate that open question from testing the host’s own recovery path. A useful crash-injection matrix is: stop before submit, after submit but before ack, after ack but before the host records it, and during result persistence. On restart, compare the host’s durable operation ID and ledger with the supported history lookup, then retry and check for duplicate external effects. This can characterize caller-side recovery without treating JSON-RPC success as a durability guarantee.\n\nDisclosure: I work with BOMTOBE on Orke, a desktop workspace for Codex and Claude Code: https://orke.bomtobe.com/