App title-generation helper threads lack an originating-thread relationship in native OTel logs and traces

What variant of Codex are you using?

App (Windows)

What feature would you like to see?

The Codex App should expose a stable relationship between an automatic title-generation helper thread and the visible thread for which the title is being generated.

Problem

The current App flow appears to start title generation as a separate ephemeral root thread.

The helper receives its own conversation.id, but native OTel logs and traces do not expose a stable field that identifies the visible originating thread or session:

• OTel logs and trace-safe events contain the helper's own conversation.id.
• Trace spans may expose session_init.ephemeral = true, but do not include the originating thread ID, shared session-tree ID, forked_from_id, or a title-generation purpose.
• The thread/name/set request span records the RPC method and request ID, but not the target thread ID.
• OTel metrics contain aggregate tags such as session_source, model, and originator, but no per-thread identifier that could restore the relationship. This request does not require adding high-cardinality IDs to metrics.

As a result, an observability consumer can detect that an ephemeral helper-like thread ran, but cannot deterministically determine that it generated the title for a particular visible thread.

Downstream observability systems must currently count the helper as an independent root session or classify it as unattributed activity. Dropping every parentless or ephemeral thread is not safe because valid user-created root threads and other legitimate ephemeral workflows can have the same shape.

Timestamp or model-based correlation is not reliable because users may rename a thread manually while automatic title generation is running, and other internal helper calls may use the same model.

Desired behavior

When the App creates a title-generation helper, it should provide both:

1. An explicit purpose, such as thread_source = "title_generation".
2. A stable relationship to the originating thread, such as:

• originating_thread_id,
• related_thread_id,
• or membership in the same session_id tree.

That relationship should be available in native OTel logs and traces.

The exact field names are flexible. The important requirements are:

• The helper keeps its own thread/conversation ID.
• The visible originating thread can be identified deterministically.
• Title generation can be distinguished from other internal or ephemeral calls.
• The relationship remains available when otel.log_user_prompt = false.
• No prompt content or generated title content needs to be exported.

Why enabling more OTel signals does not solve this

Enabling logs, traces, and metrics together provides more execution detail, but none of the three signals currently supplies the missing originating-thread relationship.

Optional W3C trace-context propagation could represent request causality if the App explicitly supplied it, but it would still be a transient tracing relationship rather than a stable session/thread ownership contract.

Additional information

Observed with:

• Codex App: 26.707.8168.0
• Bundled codex-app-server: 0.144.0-alpha.4
• Platform: Windows

Relevant public code:

• OTel log/trace events attach each thread's own conversation.id, but no session relationship:

https://github.com/openai/codex/blob/main/codex-rs/otel/src/events/shared.rs

• Session telemetry metadata does not contain session_id, parent_thread_id, forked_from_id, ephemeral, or thread_source:

https://github.com/openai/codex/blob/main/codex-rs/otel/src/events/session_telemetry.rs

• Metrics use low-cardinality session tags and do not contain a thread/conversation ID:

https://github.com/openai/codex/blob/main/codex-rs/otel/src/metrics/tags.rs

• App-server request spans do not record request parameters or target thread IDs:

https://github.com/openai/codex/blob/main/codex-rs/app-server/src/app_server_tracing.rs

• The public Thread protocol already contains sessionId, forkedFromId, parentThreadId, ephemeral, and threadSource:

https://github.com/openai/codex/blob/main/codex-rs/app-server-protocol/src/protocol/v2/thread_data.rs

• However, thread/start has no originating-thread parameter:

https://github.com/openai/codex/blob/main/codex-rs/app-server-protocol/src/protocol/v2/thread.rs

Related but distinct issues

• #15905 requested adding each conversation's own conversation.id to OTel metrics. This request is about representing the relationship between two separate threads in logs and traces, without requiring per-thread metric labels.
• #20675 concerns root/subagent metadata in hook payloads.
• #25341 concerns persisted subagent lifecycle and top-level conversation listing behavior.

This request is specifically about the relationship between a visible App thread and the internal helper used to generate its title.