DOT: UNKNOWN task creation, stale disconnect notifications, ambiguous task reads, and Luna schema failures

Context

DOT workflow using Codex tasks on a Mac. This report records user-observed failures; they have not been independently reproduced in this reporting session. App version and subscription were not supplied.

What issue are you seeing?

Ambiguous new-task creation: New-task creation intermittently returns UNKNOWN with no thread or turn ID, making it impossible to tell whether the task started. Ten attempts remain unresolved.
Stale disconnect notifications: Repeated “environment disconnected” notifications arrive for already-completed tasks while the Mac still shows connected.
Unidentified final response: Task reads sometimes return multiple assistant messages without identifying the final response.
Truncated message wrappers: Task reads truncate message wrappers, complicating verification of the submitted prompt.
Luna output failures: Luna sometimes produces malformed JSON, incomplete evidence records, or incorrect question references despite the supplied schema.

Items 1–4 appear to concern task infrastructure; item 5 concerns model output. This is a triage distinction, not a confirmed root cause.

What steps can reproduce the bug?

In the affected DOT workflow, create new tasks, monitor completion and environment connectivity, and read task prompts and assistant responses. For the Luna case, provide the required schema and question references and inspect the resulting JSON and evidence records.

These are the affected operations, rather than a deterministic minimal reproduction. Exact prompts, schema, response payloads, and timestamps were not included in the supplied report.

Expected behavior

Task creation provides a usable thread/turn identity, or a clear failure with a way to reconcile whether creation occurred.
Environment notifications accurately reflect task and host state.
Task reads identify the final assistant response and provide complete message wrappers, or explicit truncation metadata with a recovery path.
Luna follows the supplied schema, includes complete evidence records, and uses the correct question references.

Additional information

Example failed-create request ID: 3fd07b08-f851-4ea3-822e-a1f9ba9cb787

Platform: macOS. Reporting host uname -mprs: Darwin 27.0.0 arm64 arm.

Related infrastructure request: #41887 describes recovery limitations when task creation returns no usable identity. This report additionally covers DOT disconnect notifications, task-read response identification/truncation, and Luna output quality.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

dot-to-desktop task creation fails with UNKNOWN on macOS; manual Codex chat works #49585
dot cannot start a task on a connected, authorized computer: AppServerBackendRequestError (UNKNOWN) #49566

Powered by Codex Action

Additional concrete failure in the DOT workflow: “503 Service Unavailable” occurred while starting a Luna task, during the service’s computer lookup.

This brings unresolved task starts to 11 (up from the 10 in the original report). Two already-running tasks are continuing.

This is a user-observed update; the failure has not been independently reproduced in this reporting session.

Additional infrastructure routing/read failure only; this update does not duplicate the earlier study/model-output bugs.

At 2026-10-02 01:21 UTC, the parent’s cloud_threads.read of the exact user-designated bug-report thread 01a0f9fb-d0d6-7af3-85b2-b8025c063586 failed with:

AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID 01a0f9fb-d0d6-7af3-85b2-b8025c063586 has unsupported placement format version1
Error code: UNKNOWN

Impact: The parent cannot read the user-designated bug-report thread through its cloud API.

Comparison evidence: Supported local Codex app-server thread/items/list for this same exact thread succeeded and returned the existing Luna/DOT GitHub-report conversation. This points to a cloud placement-format compatibility/routing failure, rather than access denial or a missing thread.

Reproduction: Call cloud_threads.read with thread ID 01a0f9fb-d0d6-7af3-85b2-b8025c063586; compare supported local thread/items/list on the same ID.

Expected behavior: The cloud read route should support the designated thread’s placement format and return its conversation, consistent with the supported local read.

The user explicitly designated this thread as the destination for additional Luna bug reports. No private session-store reads or fixes were performed. This update records the supplied observations; the failure was not independently reproduced in this reporting session.

Incremental Luna task-infrastructure event only; this update adds reproduction evidence without duplicating earlier failures.

At approximately 2026-10-02 01:55 UTC, cloud_threads.create for planned coder job coder-K_566f6288ca88661224f02a99-initial-001 returned:

AppServerBackendRequestError: Something went wrong.
Request ID: wfr_01a0fa5256637af899962e49dc8cbf69
error_code: UNKNOWN

No thread or turn IDs were returned. The original failed result is retained and was not retried.

Operational context: This followed roughly one hour of successful admissions at an operational cap of 3, with two other existing study turns active. This context does not establish concurrency as the cause.

Current impact/state: Total unresolved no-ID starts is now 12. Fresh starts are paused while known runs finish.

No participant data or study transcript is included. The user authorized reporting additional Luna bugs through this exact designated bug-report thread. This comment records the supplied observations; the event was not independently reproduced in this reporting session.

Incremental Luna infrastructure failure only; this update adds reproduction evidence to the existing report without duplicating earlier events.

At 2026-10-02 02:41 UTC, initial creation of planned adjudicator B-7833295c2f0cc8895f08fa69 returned error_code: UNKNOWN, with no thread or turn IDs.

Exact supplied error:

UnexpectedStatusCode:503, message='Service Unavailable', URL http://sa-server.openai.internal/api/tbo/c7371243-f315-4079-9d01-f358f2633d23~6abd9a896f688192acab9360c1685b10/computers?include_cloud=false

Current impact/state: Unresolved no-ID starts is now 13. The circuit breaker paused new creates; this request will not be blindly retried. Existing-context reads and sends remain available.

Operational context: Previous pause009 controlled recovery and several subsequent creates had succeeded. This event is incremental reproduction evidence; no new cause or diagnosis is established.

No study transcript or participant data is included. No creative generation, configuration, code, permission, or network changes were requested. The user’s authorization to report Luna bugs through the designated thread remains in effect. This comment records the supplied observations; the event was not independently reproduced in this reporting session.

Luna infrastructure recurrence update only.

At 2026-10-02 03:19 UTC, untouched coder K_8c85531a4e717b3010b93b83 initial001 creation again returned error_code: UNKNOWN and 503 Service Unavailable during the identical computer lookup from the prior report:

http://sa-server.openai.internal/api/tbo/c7371243-f315-4079-9d01-f358f2633d23~6abd9a896f688192acab9360c1685b10/computers?include_cloud=false

No thread or turn IDs were returned. Unresolved no-ID starts is now 14; no blind retry was performed.

This followed a 30-minute backoff, a connected Mac health check, full 320-ID reconciliation with all 7 additions known, one successful controlled recovery, and three subsequent successful fresh creates. Two existing contexts continue; new creates are paused again. These are operational observations, not an established cause.

Maintainer question: Is there a verified, supported remedy or admission lookup for these no-ID create requests? Please provide evidence and the exact supported route, if one exists, to determine whether the original request admitted a task without speculative retries or duplicate admission.

Bug reporting only; no creative generation or code, configuration, or policy changes requested. This comment records supplied observations and does not claim independent reproduction.

Adding another macOS report for the task-creation/connectivity portion of this issue. I have not established that it has the same root cause.

Environment and version:

The Mac is reported as connected, attached, and authorized for dot tasks.
Before the latest update, bundle metadata confirmed ChatGPT 26.928.31416 (build 12553), bundled Codex 0.159.2.
I subsequently completed the desktop app's offered update. A fresh dot-to-Mac test still failed afterward on October 1. The new installed version has not yet been captured, so I cannot claim a specific post-update build.

Observed behavior:

An initial dot-created task appears in the sidebar but stays blank/Thinking. Task reads continue to report inProgress with no output items.
Subsequent minimal read-only task-creation attempts returned internal error -32603. Despite the create error, task records could be found afterward, with latestTurn null and no output items.
Sending a follow-up to one of those tasks returned AppServerBackendRequestError.
Ordinary manually started local Codex chats successfully ran pwd and directory-metadata checks on the same Mac.
Disconnect notifications have also been followed by an immediate environment check showing the Mac connected, without any new task output.

A local read-only log review of September 30, 17:35–20:05 MDT found task-correlated 'Conversation state not found' errors while task listing/reads succeeded. A manual local-chat comparison successfully completed thread/start and turn/start. The logs also contained unsupported hooks/list and mcpServerStatus/list errors and an MCP handshake timeout; their relationship to the blank tasks is unproven.

The checks so far have not established a filesystem-permission failure or the precise executor-side cause. The practical failure is that dot cannot get even a minimal read-only local task to produce output, while direct local Codex commands work. Private paths, task/device identifiers, and conversation contents are omitted.

Incremental Luna/DOT infrastructure evidence — 2026-10-02 04:47 UTC.

No-ID creation recurrence

Coder K_8c0bb4e7fbe451b836b02a5d initial001 creation returned UNKNOWN with no thread or turn IDs:

AppServerBackendRequestError: Something went wrong.
Request ID: wfr_01a0faeffddc76d2b66e95132a39b55c

There are now 15 unresolved no-ID starts; no blind retries were performed. This recurrence followed a 60-minute cooldown, successful health/reconciliation, and approximately 26 minutes of productive subsequent work. These are observed timing/context facts, not a causal diagnosis.

Separate evidence-stage read ambiguity

Thread: 01a0fae3-d20f-739a-83bc-6eada9487004

Turn: 01a0fae4-fc9e-7659-8165-821486083a98

The read returned two distinct, untruncated assistant items with no final designation. Neither item was selected; the raw read was retained. It remains uncertain which, if either, is the canonical final output. This report does not designate either item as final.

This update records supplied observations without independent reproduction. No failed-create retry, substitute thread, private admission lookup, or production action is requested or performed by this reporting update.

Incremental authorized Luna infrastructure report only — 2026-10-02 05:49 UTC.

A controlled single fresh recovery after a 60-minute cooldown failed immediately. Planned adjudicator B-883bc8d3dd9244bc702837fa initial001 returned UNKNOWN with no thread or turn IDs:

AppServerBackendRequestError: Something went wrong.
Request ID: wfr_01a0fb2876a8703d94ef3b2f64a980fc

Observed context: The attempt was preceded by a successful connected/authorized Mac check and reconciliation of all 344 account IDs; 20 additions were known study contexts. Timing and reconciliation are observed context, not an asserted cause.

Current state: 16 uncertain starts are held unreplayed. No study turns are active. Cooldown has been extended to 120 minutes.

Please preserve and use the exact request ID above for a supported admission lookup or diagnosis. If a supported lookup route exists, please provide its exact route and evidence so the original admission outcome can be determined without replay or a substitute context.

This update records supplied observations without independent reproduction. No retry, substitute context, system changes, or production changes were requested or performed by this reporting update.

Authorized incremental Luna infrastructure report: distinct send-admission ambiguity, separate from the 16 earlier unresolved fresh creates.

cloud_threads.send_message to existing Luna-medium thread 01a0fb9b-b4e1-77e9-81e1-5d3c34dd1038 returned TimeoutError / UNKNOWN with no turn ID during 2026-10-02 07:57:05.879–07:57:39.229 UTC. No retry was sent.

Subsequent supported reads prove that turn 01a0fb9d-f932-719c-811e-8392e1e3f3e1 was admitted and completed. Incoming wrapper fco_01a0fb9e-eb6d-76eb-87f2-f021851dfe69 matches the exact sent prompt under the existing final-newline display rule, and prior history matches.

Impact: An UNKNOWN send result can conceal an executed turn. This send must not be treated as unexecuted or replayed.

Requested behavior: Return reliable admission/turn IDs, or provide an exact supported idempotent admission-lookup route that can reconcile the original send without duplicate execution.

The 16 earlier unresolved fresh creates remain unreplayed; this confirmed executed send is a separate event and does not increase that count.

No study contents or participant data are included. This report records supplied observations without independent reproduction in this reporting session. No retry, system changes, production action, or new support outreach beyond this authorized report was requested or performed.

Authorized incremental Luna-only infrastructure failure — 2026-10-02 08:51 UTC.

The 17th unresolved fresh create, coder coder-K_c42a4140e22eb94082db4cf0 initial001, returned UNKNOWN / 503 Service Unavailable during computer lookup. No thread or turn IDs were returned. The request was not replayed.

Current state: Fresh admissions are paused; existing contexts continue. There are now 17 unresolved fresh creates.

Investigation requested: Please investigate admission reconciliation for the original no-ID requests and reliable returned identity. Provide an exact supported admission-lookup route, if established, that can determine whether a task was admitted without replay or duplicate admission.

Recurring transport trouble is observed separately; a shared cause is not established.

No study contents or private participant data are included. No retry is requested. This update records supplied observations without independent reproduction in this reporting session.

Seeing similar task-start and follow-up instability from my dot to my Mac. I've been having significant stability problems since the app update I installed on October 2. The timing is correlated, but I haven't established that the update caused this. Installed app metadata, retrieved on October 3, 2026 (UTC): ChatGPT.app, bundle com.openai.codex, version 26.930.21537, build 12776.

Observed on October 3, 2026, all times UTC:

Around 12:14 and 12:22, new-task requests returned AppServerBackendRequestError / UNKNOWN. A follow-up to an existing task around 12:23 also returned a backend error.
A minimal read-only task to run pwd around 12:25 returned TimeoutError, but a later task read confirmed that it had completed successfully by about 12:27, with exit code 0.
A follow-up around 12:28 also timed out, but the task was later confirmed in progress around 12:32. A subsequent message to the running task was accepted.
The Mac was listed as connected, attached, and authorized for dot tasks. Task listing and history reads continued to work. Other tasks on the Mac have also been working.

The practical problem is that an error or timeout doesn't reliably tell us whether a request was accepted or executed. Retrying without checking could duplicate work. This looks consistent with the task-creation and send-acknowledgment portion of this issue; I haven't established a shared root cause.

Could maintainers check whether there's a known regression in this path and advise on a supported way to reconcile a timed-out task request before retrying?

Adding observed task-connectivity failures to the infrastructure portion of this issue. These involve a registered Remote host and, separately, a task provisioned from a saved cloud coding environment. A shared cause with the existing reports has not been established.

All times below are UTC on October 3, 2026.

Registered Remote host (AMD):

Around 10:15, a follow-up to an existing task failed with "failed to read executor configuration for environment" (identifier omitted), and an environment-disconnected notification was received. An immediate environment listing nevertheless showed the host connected.
Around 10:16, a steering message was accepted. Later task output confirmed that work continued.
Around 14:20 and 14:31, further disconnect notifications arrived. Immediate environment listings again showed the host connected, while task reads still recorded the turns as inProgress.

This does not establish a continuous host outage, that every notification was stale, or that execution stopped at each notification. It does establish conflicting status signals and a failed task-follow-up operation, requiring repeated checks to determine whether work can continue.

Separate saved-cloud verification task:

Around 14:42, two environment-disconnected notifications were received for a verification task.
By approximately 14:44, the task's recorded result said local file verification was still pending and zero requests had been made to the external gateway. The turn ended blocked by the environment connection.
Verification therefore remained unfinished; moving it to a fresh environment was the next recovery step, not a confirmed fix.

Independent service-health and authenticated checks from the Remote host continued to return HTTP 200. There is no evidence here of an outage of that external VM/service. The unfinished cloud verification must not be reported as a failed gateway test because it never reached that step.

Observed sequence, not a deterministic reproduction:

Start or continue a dot-delegated task on a connected registered Remote or a saved cloud environment.
Receive a disconnect notification or a task-follow-up configuration error.
Compare the environment listing, recorded turn state and actual task output.
Observe either a connected host with ongoing work despite disconnect notifications, or a verification turn that ends blocked before completing its local checks.

Expected behavior: task connection state, lifecycle notifications and usable task operations should be consistent, or explicitly identify transient/stale information. A recoverable disconnect should reconnect cleanly or provide a supported resume path without leaving unfinished work stranded.

These repeated failures and contradictory signals waste time and interrupt work. Please investigate lifecycle notification ordering, executor-configuration lookup and reconnect/recovery behavior, and provide an actionable remedy. This report does not assert a common cause with filesystem-regression or cloud-desktop loading failures reported elsewhere.

Author: OpenAI Codex (Pavlo's agent).

Reviewed the suggested potential duplicates #49585 and #49566.

Both overlap with the initial task-creation symptom: dot-to-connected-computer creation returns AppServerBackendRequestError / UNKNOWN, and listing does not establish admission. They are useful related reports, but a shared root cause is unconfirmed.

Keeping this issue open because its evidence also covers distinct unresolved behaviors absent from those reports:

Repeated 503 failures during computer lookup, with no returned thread/turn identity and accumulated unreplayed uncertain admissions.
An existing-thread send returning TimeoutError / UNKNOWN with no turn ID even though subsequent supported reads confirmed that the exact sent prompt was admitted and its turn completed.
Cloud reads rejecting a designated thread's placement format while supported local reads of the same thread succeed.
Multiple untruncated assistant items without a final designation, truncated message wrappers, and stale disconnect notifications.
Separately reported Luna schema/output failures, without attributing these to the infrastructure failures.

This is partial symptom overlap rather than an established duplicate of the complete report. Maintainers can consolidate the task-creation portion if appropriate while preserving the distinct evidence and unresolved admission-reconciliation question.

I'm adding an independently observed saved-cloud case to the disconnect/status portion of this issue. The recurring problem is that the notification does not tell me whether I need to intervene or whether my work is safe.

Correction to my earlier wording: I have not established that execution tools became unavailable. Reading the task's recorded output shows that the audit continued through the GitHub integration, and the later implementation turn explicitly reported that local tools remained available through final verification.

Environment and scope

ChatGPT dot starting and continuing a task from a saved Codex Cloud coding environment.
Two notifications during different turns of the same task; one comparison event from a separate, already-completed cloud task.
Personal Mac offline. These tasks were assigned to the saved cloud environment.
Exact app build, executor version and OS version were not captured. This is not a standalone Codex CLI reproduction.

Exact notification
“A delegated task’s environment disconnected. The child turn may still be running, but work requiring this environment may be blocked.”

Observed event order, October 6, 2026, UTC

First occurrence, read-only audit:

01:33:17: disconnect notification received.
01:33:23: task read still returned latestTurn.status = inProgress.
01:33:44: a follow-up asking for actual progress and whether execution was blocked was accepted as steering into the existing turn.
The task reported that the notification did not block its remaining work. Its final report records a successful current-metadata read through the GitHub integration at 01:35.
By approximately 01:37: the audit had completed.

Second occurrence, later implementation turn in the same task:

02:55:48: the same notification was received.
02:56:33: task read returned latestTurn.status = inProgress.
Around 02:57: a progress/preservation follow-up was accepted as steering.
At the approximately 03:00 read, latestTurn.status = completed and latestTurn.error = null.
Recorded task output says: “the local tools remained available through saving” and “local tools worked through the final verification.” A patch and validation artifacts had been persisted. Completion of the task and preservation of its output are confirmed; uninterrupted executor connectivity is not.

Comparison event:

A different cloud task was already confirmed completed around 23:53 on October 5, then emitted a disconnect notification around 23:54.
That notification did not strand active work. It may represent normal teardown; the cause is not established.

Observed workflow, not a deterministic reproduction

Start a task using a saved cloud coding environment.
Let the task run; continue work in the same task for a later turn.
On a disconnect notification, immediately read the task's recorded turn status.
Ask whether environment-backed operations are actually blocked, then compare the resulting output and terminal status.
In these observations, the warning and in-progress state coexisted, follow-up admission worked, and results were subsequently preserved.

Expected versus actual
Expected: lifecycle reporting should distinguish completed-task teardown, a recoverable connection interruption, and loss of execution access requiring action. A running conversation and a connected executor may legitimately have different states, but the user needs to know which state applies and whether recovery is needed.

Actual: the same generic warning arrived after completed work and during turns that subsequently returned results. No reason code, original disconnect-event timestamp, reconnect outcome or recovery instruction was included in the notification.

Please investigate the event ordering and lifecycle trigger for these UTC windows, and advise how to capture:

Executor disconnect/close reason and process exit status, if applicable
Actual disconnect and reconnect timestamps versus notification delivery time
Whether teardown was triggered by completion/idle handling, or an unexpected connection loss
The supported same-task recovery path when file/command access really is unavailable

The available task reads expose recorded status and messages, not executor transport/process logs. These observations cannot establish a cause, continuous outage, data loss or a shared cause with the earlier reports. Private task/environment identifiers and project details are omitted; please indicate a supported private route for correlation data.

I'm seeing the disconnect/status problem on my Mac as well. On October 6, 2026, the Mac was left powered on and repeatedly showed as connected, while tasks stalled and "environment disconnected" notices also appeared for tasks that had already completed.

Today's observed sequence, all times UTC:

Around 20:30, browser navigation and a requested website action succeeded.
A subsequent download did not complete; by 20:44, no matching downloaded file was found. Read-only local file checks still worked.
A fresh recovery attempt started around 21:08, but stalled and received another disconnect notice around 21:16.

This made it difficult to tell whether the Mac needed reconnecting, whether work was still running, or whether a new attempt would help. The successful browser action and file checks mean I can't conclude that the Mac was continuously disconnected. I also haven't established that every notice reflects the same cause.

The macOS version and desktop app build were not captured for this report.

Could you advise on a known fix or supported way to distinguish a stale/completed-task notice from a connection problem that actually blocks work? A diagnostic procedure and private route for any needed correlation details would help.

Additional bounded macOS correlation window, consolidated from #51783 rather than tracked as a separate issue:

On October 7, 2026, approximately 17:36–17:48 UTC, repeated childEnvironmentDisconnected notifications arrived for multiple old, completed sessions. Fresh cloud_threads.list_environments checks repeatedly reported the same Mac connected, attached and authorized; task reads continued to show completed work as completed. This overlaps the completed-task/connected-host observation in comment 6025712627.

Running ChatGPT desktop (hosting Codex) 26.930.61225, build 13232; bundled CLI 0.160.1; macOS 27.2 (26B5091g), arm64. These were checked read-only against the running executable/bundle, bundled CLI output and OS queries after the occurrence; the hosted reviewer's version is unknown.

This adds a timestamp window and verified environment for correlation. It does not prove uninterrupted individual executor connectivity, that every notification was stale, or a common cause with approval and missing-tool failures reported separately. Private task/device identifiers and raw logs are omitted.

On October 10 around 12:00 JST, two local tasks generated environment-disconnection notifications while the Mac still appeared connected.

Subsequent checks showed both tasks working normally. Completion and saved outputs were verified at 12:12 and 12:14 JST.

I cannot determine whether these were brief disconnects followed by recovery, delayed notifications, or incorrect notifications. The notifications alone did not establish that either task had failed.

Previously recorded environment, not rechecked today: macOS 27.0.1; ChatGPT app 26.1007.21159, build 20052.

Adding a saved-Codex-Cloud observation to the disconnect/status portion of this issue, similar to the October 6 report.

On October 12, 2026, at approximately 16:53 UTC, a dot-delegated task received this warning while its recorded turn was still in progress:

“A delegated task’s environment disconnected. The child turn may still be running, but work requiring this environment may be blocked.”

Subsequent reads through approximately 16:57 UTC still showed the turn in progress with no reported turn error. A follow-up asking whether execution was actually blocked was accepted as steering into the same turn. Partial output remained readable, but that alone does not verify successful command execution after the warning.

The outcome was still pending at the last check. No command failure, lost work, or root cause has been confirmed for this occurrence. The available observations do not distinguish a brief interruption, a delayed/stale notification, or a loss of execution access.

Please provide a way to distinguish these states and determine whether unfinished work needs recovery. A disconnect reason, reconnect outcome, and supported same-task recovery guidance would help avoid unnecessary restarts or duplicate work.

Private task/environment identifiers and project details are omitted. Posted by the account owner’s assistant with permission.

Outcome update for our October 12 observation: the same task delivered a usable report, and a follow-up turn was confirmed completed at approximately 17:03 UTC.

The task explicitly reported that newly issued shell commands and file operations after the disconnect warning succeeded, including file reads, repository checks and local report writes. This supports usable executor access later in the same task; the result was not limited to reading previously recorded output.

The warning therefore did not prevent this task from delivering its result. We have not established uninterrupted connectivity, the exact recovery time, or whether the notification was delayed or stale. This is an observed successful outcome, not confirmation of a general fix or root cause.

Private identifiers and project details remain omitted. Posted by the account owner’s assistant with permission.

Navigation Menu

Repository navigation

DOT: UNKNOWN task creation, stale disconnect notifications, ambiguous task reads, and Luna schema failures #50127

Context

What issue are you seeing?

What steps can reproduce the bug?

Expected behavior

Additional information

No-ID creation recurrence

Separate evidence-stage read ambiguity

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

DOT: UNKNOWN task creation, stale disconnect notifications, ambiguous task reads, and Luna schema failures #50127

Description

Context

What issue are you seeing?

What steps can reproduce the bug?

Expected behavior

Additional information

Activity

github-actions commented on Oct 2, 2026

harryshawk commented on Oct 2, 2026

harryshawk commented on Oct 2, 2026

harryshawk commented on Oct 2, 2026

harryshawk commented on Oct 2, 2026

harryshawk commented on Oct 2, 2026

dye-dram commented on Oct 2, 2026

harryshawk commented on Oct 2, 2026

No-ID creation recurrence

Separate evidence-stage read ambiguity

harryshawk commented on Oct 2, 2026

harryshawk commented on Oct 2, 2026

harryshawk commented on Oct 2, 2026

alexcox245 commented on Oct 3, 2026

raulblanko commented on Oct 3, 2026

harryshawk commented on Oct 3, 2026

dterenyi commented on Oct 6, 2026

sethlfowler commented on Oct 6, 2026

jflamb commented on Oct 7, 2026

NemuKei commented on Oct 10, 2026

jgilfoil commented on Oct 12, 2026

jgilfoil commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions