Feature/source-evidence request: host-native one-shot operator-turn continuation for app-server clients

What variant of Codex are you using?

Codex App and Codex App Server on Windows

What feature would you like to see?

Summary

We are evaluating a safety-sensitive app-server integration that needs to
pause at one bounded operator prompt and then resume the original host-owned
asynchronous continuation exactly once.

The integration must preserve the same host task, continuation, runtime
isolate, owner instance, and privately owned child-process resources across
the operator-facing turn. It must fail closed on deadline, cancellation,
owner loss, duplicate replies, or incomplete cleanup evidence.

The documented tool/requestUserInput, turn/steer, and experimental
process/* methods do not by themselves establish those properties. We do
not want to combine low-level protocol methods into an unsupported capability
or introduce a public process/continuation handle, local IPC mailbox,
reattachment, or replay mechanism.

We are therefore requesting either:

1. identification and documentation of an existing official host-native

capability with the semantics below; or

1. consideration of a small official Interface implemented as a deep host

Module, together with the source/build/provider evidence needed to evaluate
and test it.

Requested public Interface

The project-facing Interface should remain handle-free and small:

type OperatorTurnRequest = Readonly<{
  prompt: BoundedStaticPrompt;
  replyContract: "operator-turn.v1";
  actionDeadline: HostMonotonicInstant;
  signal: HostAbortSignal;
}>;

type OperatorTurnOutcome =
  | Readonly<{
      kind: "resumed";
      reply: BoundedHostDeliveredReply;
      receipt: NativeHostReceipt;
    }>
  | Readonly<{
      kind: "not_armed";
      reason:
        | "deadline_too_close"
        | "already_active"
        | "cancelled"
        | "host_unavailable";
    }>
  | Readonly<{
      kind: "aborted";
      reason: "deadline" | "cancelled";
      receipt: NativeHostReceipt;
    }>
  | Readonly<{
      kind: "aborted";
      reason: "continuity_lost" | "owner_failed";
    }>;

interface NativeControlHostContinuation {
  readonly featureId: "native-continuation.v1";
  awaitOperatorTurn(
    request: OperatorTurnRequest,
  ): Promise<OperatorTurnOutcome>;
  verifyAndConsume(
    receipt: NativeHostReceipt,
  ): HostAttestationProjection;
}

The names are illustrative. The required semantics are more important than
the exact spelling.

awaitOperatorTurn() may mint and return a receipt, but it must not consume
that receipt internally. The only consumption point is the caller's immediate
verifyAndConsume(receipt) call while the original owner is still live and
before owner exit. A continuity_lost or owner_failed outcome returns no
receipt and has no receipt-positive verification path.

Required semantics

The official host implementation should own and hide:

• the original asynchronous continuation and task lease;
• the same runtime isolate and owner instance;
• private child-process handles and inherited pipes;
• a monotonic action deadline;
• one atomic resume-or-abort latch;
• prompt commit, cancellation, owner-loss, and shutdown coordination;
• receipt construction and single-use verification; and
• cleanup plus external owner-reap observation.

Before the prompt becomes visible, the host should atomically verify that the
deadline is still usable, install the lease/latch and cancellation hooks, and
commit the prompt. A commit failure must remain a zero-visibility
not_armed result.

After visibility, a bounded reply, cancellation, deadline, interruption,
shutdown, or owner failure must compete through one atomic winner. A late,
duplicate, stale, or mismatched reply must not extend the deadline, create a
second continuation, or authorize a retry.

The receipt should be:

• created only by the official production host;
• returned unconsumed by awaitOperatorTurn() only for a host-confirmed

resume or a known-owner deadline/cancelled abort;

• opaque and non-serializable to callers;
• bound to the exact host/provider and continuation result;
• consumed exactly once, only by verifyAndConsume() before owner exit; and
• unable to be minted or validated by a fake/test Adapter, ordinary JSON,

nonce, callback, or project plugin.

continuity_lost and owner_failed must never return a receipt. Missing,
late, duplicated, replayed, or post-exit verification is fail-closed.

A pre-exit continuation result should not self-attest owner exit or cleanup.
Those facts should come from a host-owned post-exit observation and be bound
to the pre-exit result before any capability-positive verdict is possible.

Explicitly rejected fallbacks

The requested capability should not require or expose:

• a public continuation or process handle;
• caller callbacks or a generic command dispatcher;
• a project-supplied production provider;
• a plugin or environment-variable fallback;
• repository IPC, a shared file, sidecar, mailbox, queue, or daemon;
• persisted continuation state;
• reconnect, reattachment, replay, respawn, or automatic retry; or
• a fake Adapter that can produce production-positive evidence.

Existing app-server protocol methods may be used internally by the official
host, but caller-side composition of tool/requestUserInput, turn/steer,
and process/* should not be treated as proof of this capability.

Source and provider evidence requested

Could the maintainers identify, or confirm that the following is not publicly
available?

1. the exact app-server source revision used by a given released build;
2. the reproducible app-server build entrypoint and target;
3. the canonical source root and build entrypoint for Codex Desktop;
4. the native binding or host Module that owns Desktop-to-app-server

continuation behavior;

1. the compatibility mapping between a Desktop release, app-server release,

native binding, and production Adapter;

1. release provenance tying the shipped provider to exact source and build

inputs;

1. the official owner of provider construction and receipt verification;
2. the feature-discovery mechanism for determining whether the official

provider is callable; and

1. the revision-bound source files and tests that would form an appropriate

implementation or review allowlist.

For context, the observed Windows release pairing that prompted this question
is:

Codex Desktop package: 26.727.6591.0
@openai/codex: 0.147.0-alpha.4
@openai/codex-win32-x64: 0.147.0-alpha.4-win32-x64

These version strings and the observed Desktop-to-app-server process lineage
are not being presented as source or provider provenance. We are specifically
requesting the authoritative mapping rather than inferring it.

Maintainer questions

1. Does an official host-native equivalent of the requested Interface already

exist? If so, what is its supported feature identifier and documentation?

1. Can it preserve one original host continuation and privately owned child

resources across a later operator reply without exposing a public handle?

1. What code owns the atomic resume-or-abort race and the monotonic cutoff?
2. Is there an official single-consume receipt or attestation mechanism that

proves the exact continuation result rather than merely transporting a
client-supplied opaque token? If so, can the official contract confirm that
the awaited operation only mints/returns it and that verifyAndConsume() is
the sole pre-exit consumption point?

1. How can a client verify post-exit owner reap and cleanup without relying on

owner self-report?

1. Which source revision, build target, Desktop binding, version map, and

conformance tests should be reviewed for the Windows versions above?

1. If this capability does not exist, would the maintainers accept a focused

design or implementation proposal for the official host Module and thin
Desktop Adapter?

1. Which repository venue and labels are preferred for the next discussion?

Suggested conformance coverage

An official implementation would be considered suitable only after tests
cover at least:

• a real two-phase operator interaction where the first phase returns before

the later reply resumes the original continuation;

• same task, continuation, runtime isolate, owner instance, child, and pipes;
• exactly one arm, one resume-or-abort winner, one terminal result, at most one

receipt mint, and exactly one pre-exit consumption for receipt-bearing
outcomes;

• prompt-commit failure before visibility;
• reply/cancel/deadline/interruption/shutdown/owner-loss races;
• early, duplicate, stale, mismatched, late, and exactly-at-cutoff replies;
• owner-loss containment and external reap;
• cleanup of timers, listeners, leases, pending promises, children, and pipes;
• fake/production provider isolation;
• rejection of ordinary JSON, caller fields, replayed receipts, and wrong

providers; and

• bounded evidence that contains no raw continuation, process, account,

credential, path, or file identifiers.

Non-goals

This request does not ask the app-server protocol to perform a marketplace
upload, browser action, file selection, or business operation. It does not ask
for credentials, account data, cookies, tokens, file paths, file contents, or
reusable session material.

It also does not request a project-specific fallback. If the official host
cannot provide the required semantics, the safe result for our integration is
to remain blocked rather than emulate the capability with lower-level
primitives.

Thank you for guidance on the supported host capability and the authoritative
source/build/provider evidence needed to evaluate it.

Additional information

Official references:

• https://learn.chatgpt.com/docs/app-server
• https://learn.chatgpt.com/docs/open-source

Related but not exact duplicates:

• #25914 — external Desktop-thread discovery/attachment; this request deliberately avoids external attachment or public handles.
• #20943 — external lifecycle events; this request additionally requires same host continuation, single-consume receipt authority, and post-exit cleanup binding.
• #30150 — structured user questions in Desktop Default mode; this request is about host-owned continuation semantics, not tool availability alone.
• #25544 — requestUserInput documentation naming; this request does not depend on that naming discrepancy.