External technical engagement evidence — OpenAI Codex thread addressability discussion #162

Classification

EXTERNAL_TECHNICAL_ENGAGEMENT / IMPACT_EVIDENCE

This record preserves a technically substantive external interaction in the OpenAI Codex repository. It is not ExecSurface validation, adoption, endorsement, reproduction, or P8 execution evidence.

External source

OpenAI Codex issue:
openai/codex#49729

AETHER X synthesis:

• Dot cannot create or follow up with local Codex tasks in saved projects openai/codex#49729 (comment)
• Dot cannot create or follow up with local Codex tasks in saved projects openai/codex#49729 (comment)

Representative independent reports discussed in the synthesis:

• Windows native-helper positive control / parent-route failure:
  Dot cannot create or follow up with local Codex tasks in saved projects openai/codex#49729 (comment)
• macOS fresh-helper positive control / parent-route failure history:
  Dot cannot create or follow up with local Codex tasks in saved projects openai/codex#49729 (comment)

Technical contribution

The discussion isolates a control-surface identity boundary:

thread existence/validity != addressability from every control surface

The first AETHER X comment framed the problem as an identity/placement contract split and proposed an opaque canonical thread reference carrying the placement/version semantics required by later read/send/monitor operations.

After additional Windows and macOS reproductions accumulated, the follow-up synthesis narrowed the likely failure boundary further by separating:

1. canonical thread identity / placement metadata;
2. parent-dot routing through cloud_threads;
3. delegated-task projection of native desktop thread capabilities.

The follow-up proposed that a valid thread should not degrade to generic NOT_FOUND merely because one control surface cannot interpret its placement, and that delegated native-tool availability should expose capability generation/state so old-helper versus fresh-helper behavior is diagnosable.

It also proposed a conformance matrix covering project-scoped creation, desktop restart/project reopen, old-vs-fresh helper capability projection, Windows/macOS placement variants, migration/upgrade behavior, and typed unsupported-placement handling.

External evidence

Multiple external reporters supplied Windows and macOS reproductions showing a recurring pattern:

• an existing local conversation remains valid and usable through at least one native/local route;
• a fresh dot-created helper can, in some cases, expose native thread tools and successfully read or message the same target;
• the parent dot's direct cloud_threads.read / send_message path can still reject or fail to locate that same known target.

These reports are useful positive controls because they reduce the plausibility of “the thread no longer exists” or “the computer is simply disconnected” as complete explanations.

Evidence boundary

What this does establish:

• substantive external technical engagement;
• a multi-reporter, cross-platform pattern relevant to thread identity, placement and routing semantics;
• evidence that the distinction between object validity and control-surface addressability is materially useful for diagnosing the reported failure class;
• a concrete testable contract and conformance matrix for future implementation/review.

What this does not establish:

• that OpenAI adopted ExecSurface;
• that OpenAI adopted the proposed canonical-reference design;
• that the external reports were caused by or derived from AETHER X comments;
• that OpenAI endorses AETHER X or ExecSurface;
• that ExecSurface itself was executed in these reproductions;
• P8-A1 zero-assistance reproduction of ExecSurface;
• P8-A4 external real-workload use of ExecSurface;
• P9.5 production evidence.

Qualification

TECHNICALLY_USEFUL_NONINDEPENDENT_TO_EXECSURFACE_VALIDATION

Reason: the external reports support the relevance of an identity/routing/evidence boundary. They do not validate the ExecSurface product.

Recommended retained wording

AETHER X contributed identity/placement and control-surface addressability analysis to an OpenAI Codex issue involving Dot follow-up to existing local tasks. Subsequent Windows and macOS reports showed that the same target conversation could remain valid through native/helper routes while the parent Dot route still failed. This is retained as external technical engagement/impact evidence, not OpenAI adoption, endorsement, or ExecSurface validation.

Product-boundary implication

No new ExecSurface product feature is authorized by this record.

Any future interoperability experiment must remain evidence-gated and must not equate successful routing with observer completeness, execution authority, or product validation.

Related internal tracking:

• external engagement: OpenSSF / Linux Foundation — Technical Community Engagement #94
• distribution/engagement discipline: Distribution Sprint — external GitHub discovery & interoperability outreach (Alpha.5) #125
• P8 external-validation boundary: P8 — External Validation, Independent Reproduction & Architecture Criticism #114
• P9.5 real-workload boundary: Post-v1 — External real-workload evidence (historical P9.5) #140
• OpenAI daemon-continuity impact record: External technical engagement evidence — OpenAI Codex daemon continuity discussion #160
• NVIDIA OpenShell execution-generation impact record: External technical engagement evidence — NVIDIA OpenShell execution-generation lifecycle discussion #161