[Dots][macOS][Pro] Delegated work stalls after task completion or approval blocker; repeated reminders needed

What version of the Codex App are you using (From “About Codex” dialog)?

Affected run: 26.928.21956 (build 12404), captured by a same-day installed-app inspection.

After the user updated and restarted: 26.928.31416 (build 12553), verified from the installed application's Info.plist. The currently bundled CLI reports 0.159.2.

The incident occurred before that restart. Read-only task/history checks were repeated after updating; a fresh Dot-delegation reproduction on the new version has not been run.

What subscription do you have?

ChatGPT Pro, as stated by the affected user.

What platform is your computer?

macOS 27.0.1 (26A434), Apple Silicon.

uname -mprs:

Darwin 27.0.0 arm64 arm

Dot in the desktop app, with a connected Mac executor. The delegated tasks are reported by the native task APIs as hostId: durable, although they execute against the Mac workspace.

What issue are you seeing?

A Dot starts delegated work, but does not reliably close the loop when the task stops before delivering the requested result or requires user input. Repeated user reminders restart a task once, then the coordination stalls again.

This was investigated on October 1, 2026 through existing task histories, live read-only task APIs, and desktop logs. It is an observed incident, not a claim that every Dot is affected.

The delegated workflow had an explicit checkpoint: finish candidate research and prepare a selection-ready deliverable, then let the human select. It was not authorized to draft or publish autonomously.

Three observed failure points:

Premature task termination. The worker marked its turn completed while explicitly saying the deliverable was only a preview: 14 candidates, six acquisition waves, required source coverage and a sealed pool unfinished. Its own final message said it was not selection-ready.
Missed parent follow-up. There was a 38-minute gap between that completed turn and the next delegated continuation. The later delegation itself acknowledged that the parent had missed the stopped task. The user reports having to remind the Dot repeatedly instead of receiving a timely follow-up.
A later approval blocker was left unresolved at the coordination boundary. The most recent reminder did start another worker turn. That worker checked its environment and then reported that automatic approval review refused the workflow resume because its original task instructions prohibited resuming that workflow. Later authorization was carried by a delegated follow-up and was not accepted as a direct human change to the original scope. The worker returned a request for direct authorization and became idle; the Dot still did not provide the expected timely coordination.

This is particularly disruptive on a paid Pro plan: the user is left manually supervising whether delegation, continuation, approval handoff, and result delivery actually happened.

What steps can reproduce the bug?

Observed workflow; a fresh minimal reproduction has not been run:

Ask a Dot to create a task on its connected Mac for a narrow Computer Use capability check, with an explicit instruction not to resume the main workflow.
After the capability check succeeds, ask the Dot to use that task for the next workflow stage, with a concrete deliverable and human-decision checkpoint.
The Dot sends follow-up instructions to the same task. The retrieved delegation messages cite the user's approval and require continued work until the deliverable is ready or a genuine blocker is reported.
The worker returns an unfinished preview and marks the turn completed.
Observe that the parent does not promptly inspect the outcome and continue the assignment. Remind it; another continuation is delivered.
After a workflow-level resume defect is repaired in a separate task, remind the Dot again. It sends another continuation to the original worker.
The worker reports an automatic-review rejection caused by the original prohibition versus the later delegated authorization, requests direct user input, and stops. The parent again fails to provide a timely, actionable follow-up.

The original human scope-change message could not be independently retrieved from the Dot parent through the available history API. The later delegation's citation of authorization and the worker's rejection report are directly readable. This distinction matters when investigating authorization provenance.

Relative execution timeline

Event	Observed timing/result
Worker finishes preview	Turn is `completed`; requested deliverable still explicitly unfinished
Next worker continuation	38 minutes after that completion
Intermediate worker stop	Application-specific resume prerequisite defect; a separate engineering task repairs it
Latest desktop reminder	Send succeeds; matching pubsub echo is received
Latest worker starts	Approximately 44 seconds after the reminder
Latest worker finishes	Approximately 2 minutes 52 seconds after starting; reports approval rejection and asks for direct authorization
Desktop first-response observation expires	Approximately 5 minutes after the reminder; no matched first reply recorded
User updates/restarts desktop	Approximately 8 minutes 26 seconds after the reminder
Post-update read-back	Worker remains `idle`; latest turn is the same completed, blocked turn; native history/monitoring reads succeed

The intermediate application-specific prerequisite defect is contextual and was repaired. It does not explain why the Dot failed to close the loop after the worker's outcomes.

What is the expected behavior?

On delegated-task completion or a request for input, the Dot should inspect the result and reconcile it with the requested deliverable. Turn completion should not silently settle unfinished work.
If work can continue within the authorized scope, the Dot should continue it through the supported Task mechanism.
If an approval or scope conflict requires human input, the Dot should promptly surface the specific decision and supported way to resolve it in the conversation where the user is coordinating the work.
Interrupted parent turns and desktop reconnection should preserve outstanding delegated responsibilities.
Users should be able to distinguish working, waiting for a task, blocked, awaiting input, and delivered. An active status alone is insufficient.
Preserve approval checks while making the original instruction, subsequent human scope change, and delegation provenance available at the appropriate authorization boundary.

The official Dots assigned-work documentation describes continued work between conversations, autonomous pause/wake decisions, checking results of tasks the Dot created, and continued coordination while the user steps away. It also distinguishes completed runs from achieved or delivered results. This report concerns that end-to-end follow-through.

Additional information

Native task read-back

After the desktop update:

read_thread successfully retrieves the worker's history and explicit blocking final.
wait_threads with the worker's durable host and timeoutMs: 0 returns wake.reason: turnCompleted, worker idle, latest turn completed, and the blocking final message.
The Dot parent's thread metadata reports active, but its latest available turn is interrupted with error: null.
Two pages of parent history return ten interrupted turns with empty items. In contrast, the worker's latest history contains its actual messages and tool items.

The parent history limitation prevents verification of its exact wait/subscription/tool sequence. Empty parent items are not proof that no monitoring tool was called. Interrupted metadata alone does not establish whether interruption came from steering, a normal orchestration boundary, or a runtime failure.

Delegation / approval provenance seam

The original task-creation input is a userMessage containing a delegation wrapper. Later send_message continuations appear as functionCallOutput items containing delegation wrappers.

The worker's final and its local persistent blocker record agree:

kind: auto-review-authorization-rejection
resumeExecuted: false
pendingDirectUserAuthorization: true
chromeRestored: true
newCandidates: 0
selectionReady: false

The reported review reason is that the original instruction forbids resuming the workflow and later delegated evidence does not establish changed direct human authorization. The raw approval-service decision was not independently available. The trusted-role/provenance transition is an investigation seam, not a confirmed root cause.

Messaging / connection evidence

For the latest reminder, the same request has:

client.send: started
client.pubsub_received: success
client.http_send: success
client.first_response: timeout; durationMs approximately 300004
client.round_trip: timeout; observationInterrupted=true

No 503 delivery-unconfirmed response was observed for this request. Send success and echo do not prove an assistant reply or delivered outcome.

The current installed client's messaging observer uses a 300,000ms observation timer. Its interruption flag can be set when the view becomes inactive or the document becomes hidden. Its timeout path records/finishes the observation. These observations are not evidence that a server-side watchdog killed the task. This static inspection was of the new installed version; the affected old bundle was not retained for comparison.

The old desktop log also contains two durable WebSocket closes with code 1006 followed by reconnection within about 1–2 seconds. Neither occurs during the latest worker's execution window. There are 303 instances of:

unsupported app-server method: mcpServerStatus/list
code: -32601

They indicate an additional discovery-method compatibility problem, but no causal link to missed follow-up was established.

Requested investigation / regression coverage

Please trace the handoff from worker turn completion/input-needed outcome to parent event receipt, parent wake, result inspection, and next-action/user notification. It would help to expose enough diagnostic state to distinguish an unsubscribed parent, lost completion event, failed wake, interrupted parent, and an agent that received the result but did not act.

Relevant regression cases: unfinished deliverable with a completed worker turn; approval conflict after reusing a capability-check task; parent interruption before worker completion; and reconnection with an outstanding delegated responsibility.

Duplicate review

Windows Desktop dots: message POST returns 503 aeon_delivery_unconfirmed; later Delivered does not yield a reply #49838: related no-reply/interrupted symptoms on Windows, but its primary evidence is HTTP 503 aeon_delivery_unconfirmed. This request succeeded, and the worker actually ran.
Dot cannot create or follow up with local Codex tasks in saved projects #49729 and Improve discovery and wrong-route diagnostics for dot continuation of local Codex chats #49482: address known-ID access/routing or tool-discovery failures. Here the worker is accessible and accepts continuation.
[Dots][macOS → Mobile Remote] Dot-created Mac tasks are missing from the task list even after pinning #49848: related mobile visibility issue for Dot-created Mac tasks; separate from the stalled coordination reported here.

No identical report was found in the searches performed. Please consolidate if the same orchestration defect is already tracked.

Private task/turn/room/message identifiers, project names, paths, full prompts, screenshots, and raw logs are omitted. Scoped evidence is retained locally; no account or security settings were changed during diagnosis.

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

[dot / Desktop] Local task awaiting approval remains in progress in the main dot conversation #49531
Codex Desktop ends unfinished long-running work after a small partial checkpoint #48677
Codex Desktop repeatedly terminates multi-step implementation turns after one intermediate subtask despite explicit continuation/acceptance criteria #49390

Powered by Codex Action

Additional evidence for the permissions and authorization handoff:

My suspicion is that Codex’s scheduling/delegation path defaults Dot-created Tasks to “Approve for me,” even when the requested workflow needs broader permissions. The observations below do not establish where that choice is made or prove that this is the root cause.

The Mac’s configured values were approval_policy=never, approvals_reviewer=user, and sandbox_mode=danger-full-access.
The delegated Task reported workspace-write, auto_review, and restricted network access. Its effective approval_policy was not independently verified.
The Task-creation interface available to the Dot exposed no permission selector.
Later, the same Task’s UI displayed “Full access” alongside a cloud label. Its effective runtime permissions were not rechecked at that point, so the earlier observations should not be assumed to describe its later state.
Browser-tool availability differed between Tasks displaying the same cloud label. Tool availability needs to be investigated separately from permissions.

There is also a further authorization-provenance observation: one retry supplied the user’s exact scope-change messages to the existing Task. The worker still reported that automatic review rejected the same workflow-resume action based on the original scope restriction and requested direct confirmation. The raw approval-service decision was unavailable, so this remains a worker-reported result.

Please investigate how Dot-created Tasks select and inherit permissions, and how subsequent human scope changes reach the approval boundary. It would help to show each Task’s effective approval policy, reviewer, sandbox/network restrictions, and the source of those settings. A supported, explicit per-Task “Full access” choice would help when the user’s workflow requires it, with safety checks preserved.

The parent should also promptly surface any remaining approval requirement and a usable way to resolve it in the coordinating conversation.

A further observation: browser/computer tools disappeared between turns of the same delegated Task, after the user resolved the authorization blocker directly in that Task.

Observed sequence on October 1:

At approximately 03:17 UTC, the Task had mcp__cua_repl.js. Its read-only capability check successfully listed Mac applications, identified the connected Chrome extension, and listed four Chrome tabs. The subsequent workflow turn used that browser channel.
The user later entered direct authorization in the Task to resume candidate exploration and source checking, while retaining the human-selection and publication checkpoints. The worker acknowledged that authorization.
In that later turn, the worker reported that Chrome/Computer Use tools were no longer available. It could still check public sources and existing records, but could not complete the remaining X discovery coverage.
A bounded follow-up capability check at approximately 06:15 UTC reported 248 available/deferred tools, with no mcp__cua_repl.js, Chrome/Computer Use control, or supported tool-discovery/loading entry point. It therefore could not call getState or listTabs again.

The evidence is the same Task’s readable history and its saved capability-check reports. The raw tool-provisioning backend was not inspected, and the reason for the changed tool set is unknown. This should be investigated separately from sandbox/approval mode; direct human authorization had already been acknowledged. A cloud label or a “Full access” UI label alone did not establish browser-tool availability.

Please include capability continuity across delegated follow-ups and direct-user turns in the investigation: which tools were supplied on each turn, why their availability changed, and how the parent can detect and surface the resulting blocker promptly. The workflow remains incomplete; existing candidates and the original timing were preserved, with no drafting or publication. No permission changes or alternate browser-control bypasses were used.

Adding a narrower observation about delegated-task progress visibility on Windows.

On October 1, at approximately 15:52 and 16:10 UTC, the cloud_threads.read calls we inspected reported the current turn as inProgress but did not return its ongoing assistant progress. Opening the same task’s full browser page showed current messages, command execution, file edits, and test progress. The recent-activity panel also appeared less current than the full task page.

By 17:16 UTC, cloud_threads.read returned completed and the actual final result. The same delegated task had accepted multiple follow-up turns and performed local work.

Opening the full task page was a useful monitoring workaround in this case. Missing fresh text in the inspected read results would have been misleading if treated as evidence that execution had stopped.

We have not established a lost completion event, failed parent wake, or the approval-provenance failure reported above. Please clarify the freshness and pagination/subscription semantics of task reads, and expose enough state to distinguish a running task with delayed history from a stalled task or an unresolved approval blocker.

My dot keeps going quiet while work is supposedly underway. I have to keep waking it up and asking what’s happening, whether it’s still working, or whether it finished. It’s frustrating, and it makes delegation feel like another job to supervise. I need proactive updates: tell me when work starts, when there’s meaningful progress, when it’s blocked, and when it’s finished. If something takes a while, give me an occasional “I’m still working on this” update with the actual status. If work stops or needs my input, say that clearly. I shouldn’t have to chase my assistant to know whether it’s doing the work it promised.

One orchestration invariant may help separate the parent/worker lifecycle from progress-display issues:

worker turn terminal state != delegated obligation discharged

A worker can finish a turn while the obligation the parent delegated is still unresolved: blocked on approval, missing a required capability, partially completed, or explicitly reporting that acceptance criteria remain open. The parent should therefore track the obligation as its own durable object rather than deriving completion only from the child turn's terminal status.

Conceptually:

delegated obligation O
-> worker attempt W1
-> result/evidence
-> acceptance check for O
-> discharged | blocked | retryable | needs-human

A worker saying completed closes W1; it should not automatically close O.

A strong recovery test would be:

parent delegates O with explicit acceptance criteria;
worker W1 reaches a terminal turn after producing only a partial result or a blocker;
parent disconnects/restarts before processing the result;
on reconnect, O must still exist as outstanding and be reconciled from the child's evidence;
a later W2 or human decision discharges the same obligation rather than creating an unrelated task.

That would also give progress surfaces a clearer source of truth: "worker is running" and "delegated obligation is complete" become separately observable facts.

I’m seeing a similar end-to-end coordination failure with dot, described in more detail here: #50482 (comment)

My workflow uses dot to coordinate cloud and connected-computer tasks, independent reviews, corrections, and quality gates. A worker’s partial result or a recoverable interruption does not reliably lead to the next authorized step. During the day I repeatedly have to ask dot to check finished work, coordinate the next stage, and continue.

On October 10 I explicitly authorized overnight continuation until acceptance criteria were met. The next morning I found no meaningful overnight progress, an approximately ten-hour gap from my perspective, not a log-verified execution duration.

The impact is constant babysitting of work I already delegated. Please preserve unfinished obligations and reconcile each worker outcome with the requested result. Genuine permission or capability blockers should be surfaced promptly so I can resolve them. I’m not requesting permission bypasses or claiming the specific approval-provenance failure in this issue caused my experience.

Additional observation on October 11, 2026, using ChatGPT on macOS: a structured consent question was visible inside a delegated build task, but the coordinating dot’s inspected task readback did not show the pending question. No corresponding input-needed notification was observed in the parent context.

The question offered to upload a verified private backup to an existing cloud-storage folder or keep it local. It was an interactive asynchronous question, not an observed tool-permission rejection. The readback showed the task in progress and described validation/recovery work.

After the user answered, a later parent read exposed the question text and submitted approval. The question was no longer pending by then.

Have observed multiple instances of this general visibility gap. Have not established whether an event was emitted or where the visibility gap occurred. ChatGPT MacOS version 26.1007.30912.

Current environment verified October 11, 2026: ChatGPT 26.1007.30912 (build 20156); macOS 27.0.1 (build 26A434).

I am extremely frustrated with Dots. Frankly, Grok Bot feels better than Dots to me right now. I keep having to supervise and chase an assistant that is supposed to keep work moving.

Two examples from October 11-12, 2026 (JST), visible in my Slack conversations:

After Dots promised to check a research question, I had to ask whether it was still checking roughly 40 minutes later. It then said the check was done but it had failed to return the result.
In a separate browser-reading task, I asked for progress at 20:22. The result did not appear in that thread until 00:05 the next day, about 3 hours 43 minutes later. Dots explicitly said it had missed reporting the result.

That interval is a reporting gap, not a measurement of execution time. I have not traced the internal cause.

Please prioritize end-to-end follow-through: keep the requested deliverable pending until it is actually delivered, surface blockers and decisions promptly, and recover unfinished delegated work without requiring repeated reminders. I want fewer supervision tasks, not another assistant whose status I have to manage.

Repeated delegated-work stalls, instruction drift, and a reported voice connection failure

Scope and evidence limits

This audit concerns one long-running ChatGPT dot development session on macOS, October 12–14, 2026. It reviews 819 distinct accessible room messages, from October 12 21:56:22 UTC through October 14 20:36:55 UTC, plus saved project artifacts. A separately identified follow-up below adds directly reported recovery events through October 14 20:40:46 UTC and the parent’s 20:39 acknowledgment. Sequential room retrieval reached the beginning of available history; 516 archived messages were cross-checked and were already included. This is the complete accessible room corpus reviewed, not a claim to possess every backend event, worker execution log, voice event, or message from the user's entire account.

The report separates (a) user observations, (b) assistant acknowledgments or reports, and (c) corroborating saved artifacts. A timestamp proves when a message was recorded, not necessarily when a backend transition happened. Exact client/build versions and backend traces are unavailable. Names, account identifiers, private links, project source, and raw transcripts are omitted.

The companion permission-card report is #54068. Simple-request response delays are documented separately in #54088. Related instruction-propagation failures are tracked in #52157; the failed-call observation is also posted in #50870. This report concentrates on continuation of delegated work, carrying instructions through execution, and inaccurate task-state/acceptance assumptions. It does not attribute every failure to a single backend defect.

1. Repeated handoff and worker-utilization failures

The user repeatedly requested efficient parallel use of six workers plus the coordinating assistant. The concern was unfinished parallelizable work remaining undispatched, not merely a worker finishing a task normally.

UTC date/time	Recorded evidence	Strength/qualification
Oct 13 03:08:57	Assistant said mouse/keyboard testing had been parked after a permission stall while builds and image checks continued.	Assistant report; not a total project freeze.
Oct 13 09:49:55	Assistant said native verification had not resumed since an optional permission prompt, while another platform's checks were complete.	Assistant report of a parked branch of work.
Oct 13 12:22:17–12:47:46	Assistant stopped game-window automation so the user could play. At 12:28:56 the user corrected the plan: prepare an isolated play copy and continue development. Assistant agreed at 12:29:06 and reported the isolated copy at 12:47:46.	Direct correction of an unnecessarily coupled play/development workflow.
Oct 13 13:01:57	Assistant acknowledged the Windows build lagged behind while Mac/Linux took priority and a capture-tool blocker held up Windows-specific verification.	Assistant report; a platform lag, not proof of zero Windows work.
Oct 13 15:33:28	Assistant acknowledged an unnecessary loop: a build the user had already closed had been reopened to close it again.	User observation followed by assistant acknowledgment.
Oct 13 15:43:34	Assistant said a simple install had become repeated checks, then a backup-configuration signature check, although the update was ready.	Assistant acknowledgment of avoidable delivery-path work.
Oct 13 17:20:37	Assistant said source was already ready but Mac build/install had spent another 16 minutes without useful status.	Assistant's contemporary report; the 16 minutes is its estimate, not a reconstructed tool duration.
Oct 13 19:24:20; 20:03:50; 20:10:22; 20:22:17	Repeated acknowledgments that completed code/checks had not become a delivered build; implementation, packaging, handoff, and gaps between steps were holding it up. At 20:03 the assistant contrasted about 70 seconds of build/check work with the much longer overall delivery.	Repeated assistant reports; the 70-second figure is not end-to-end latency.
Oct 13 22:04:46–22:05:26	Assistant reported one development worker active and no native build/GUI test running, then clarified that no new integration edits or tests had begun.	Explicit task-state report, after several hours of delivery complaints.
Oct 14 16:17:43; 16:20:40	User observed no active subtasks. Assistant acknowledged workers had finished prior assignments and it had let the permission discussion stall the next handoff.	Direct admission of parent coordination failure.
Oct 14 16:56:27	User observed one active worker and explicitly required all six workers plus the parent to be used efficiently.	User observation and clear instruction.
Oct 14 17:03:42	Assistant said it was dispatching six distinct workstreams.	Intention statement, not proof all six had started.
Oct 14 17:07:21; 17:13:12	User twice reported only two workers active.	Repeated user observations.
Oct 14 17:16:45	Assistant explicitly confirmed two active workers and four undispatched assignments, with browser navigation waiting on an approval check.	Assistant-confirmed dispatch backlog.
Oct 14 18:14:53	Assistant finally reported all six workstreams started.	Recovery report, 58m 08.587s after the two-active/four-undispatched acknowledgment. This does not mean all work was frozen for that interval.
Oct 14 20:08:04; 20:12:50; 20:18:26	User warned not to abandon the original project while preparing bug reports. Assistant said it was keeping development moving; user then reported only two workers active again.	User-reported recurrence. No independently sampled worker count is available at precisely 20:18.
Oct 14 20:34:59	Assistant acknowledged worker handoffs had not kept pace and said it was checking all six task states.	Acknowledgment, not evidence of successful recovery.

The sequence supports a recurring orchestration problem: work completion or a tool/approval interruption did not reliably cause the next authorized assignment to be dispatched. It does not establish that every inactive worker was a failure, that all tasks were continuously stopped, or that the scheduler alone caused it.

2. Latest user instructions were not consistently carried into execution

Reinterpreting small requests into the wrong work

Oct 13 19:36:23: assistant acknowledged misunderstanding a request that moving a window preserve its size; it had instead proposed a Shift-only resizing restriction.
Oct 13 19:55:05: assistant acknowledged prematurely launching the existing candidate during a delivery-pipeline test before the requested resize restriction was fixed. Proving the pipeline worked had been confused with delivering the requested behavior.
Oct 13 20:50:36: assistant acknowledged overreading a request for stable testing into a blanket GUI restriction.
Oct 13 22:00:21: assistant acknowledged overcomplicating a small supported-size restriction into a new native-window mechanism that introduced crashes.
Oct 14 00:13:10 and 00:34:49: after the user objected, the assistant agreed to remove an unrequested banner and acknowledged that wording cleanup had become an unnecessary delivery detour.
Oct 14 14:05:42: user explicitly requested generating individual graphical elements first, then composing them. At 14:18:51 the assistant reported splitting elements from an existing composition. At 14:19:45 and 14:20:25 it acknowledged having reversed the requested order and stopped slicing the finished image. Saved project guidance independently records the intended generate-elements-first workflow.

These are assistant/task-interpretation failures. No backend cause is demonstrated.

Fresh communication-route instruction violation

At October 14 20:39 UTC, the parent acknowledged sending one build-task handoff through a native messaging tool despite the user’s explicit browser-only instruction for task messages. The tool accepted the message, so it was not merely an unsent draft. The parent said it would not duplicate the accepted message and would return subsequent messages to the required browser route. This is a verified instruction-following error, separate from whether the browser was healthy; no private task identifiers or message contents are included.

Obsolete restrictions survived later authorization

Oct 14 04:04:40: user questioned a claimed earlier no-files restriction.
Oct 14 04:12:50: assistant acknowledged that the restriction came from its own earlier text-only task, not from the user. The user had subsequently authorized uploads, but the approval path was still citing the old restriction. Uploads remained blocked.
Oct 14 04:24:06–04:36:31: assistant reported that permission had passed, then the picker failed and recovery instructions timed out. Thus stale restriction handling and execution failures were distinct stages, not one missing user approval.
Oct 14 04:52:02: assistant acknowledged repeatedly retrying a stalled process instead of isolating the failure; it said the latest dispatch timed out before the worker received the instruction.
Oct 14 19:00:54: assistant acknowledged that a build worker retained an outdated deterministic-only art restriction even after newer instructions permitted fixed, hash-preserved generated assets.
Oct 14 19:02:44: assistant reported relaying the newer instructions and the worker acknowledging the change. This was a correction in progress, not verified proof that every downstream check and delivered artifact had been corrected.

Saved cloud project reference files still contain the older global art-generation ban, while later saved guidance requires separately generated elements. Those files corroborate contradictory project material, but their presence alone does not prove they still govern the current installed build.

A stated release requirement was omitted from the actual build

Oct 14 16:48:55: user required art and mechanics to progress together so each update included the remastered graphics associated with its changes. At 17:00:29 the assistant restated that requirement.
Oct 14 18:51:41–18:57:51: user opened the latest play build and reported the full scene still used the old composition, with visible seams and repeated vegetation.
Oct 14 18:58:08: assistant confirmed the release kept the previous background composition and changed only title-button assets; the independent-object composition had not been included.
Oct 14 19:00:54: assistant explicitly acknowledged failure to carry the release requirement into the build process.
Oct 14 19:04:10: assistant reported an asset audit finding nine scene elements still using legacy assets, newly prepared layers not connected to the renderer, and an older character image selected instead of the corrected one.

The failure was not merely whether a preview looked attractive: prepared work, selected versions, installed assets, and the user's release requirement had diverged. The audit outcome above is a contemporary assistant report, not a fresh independent examination of the user's installed application.

3. Checks and status claims did not always establish the user's actual outcome

Oct 13 16:05:37: after the user's actual mouse test failed, the assistant acknowledged its earlier Shift-resizing claim was too strong. At 16:27:47 it reported that its automated attempt had not actually resized the window, leaving the feature unverified.
Oct 13 18:04:11: assistant acknowledged checking output dimensions but failing to check responsiveness; rebuilding asset caches during drag caused severe lag. Correctness checks had missed practical usability.
Oct 14 01:46:09–01:55:49: assistant acknowledged that exporting enlarged artwork at 8K did not establish genuine HD detail, and that it had not clearly identified which asset-generation method actually shipped.
Oct 14 12:08:41: assistant reported a porting error had added an effect to levels that should not have it, changing shared random-number state and invalidating previous successful runs as evidence of faithful campaign behavior. A saved superseding-status artifact independently withdraws the affected campaign-continuity qualifications while preserving historical evidence. The session did not meet the user's overnight completion goal; the assistant had previously declined to guarantee that goal, so this is an unmet target rather than a broken unconditional guarantee.
Oct 14 12:32:11: assistant confirmed that an original right-click input handler had been omitted, after the user found it during play.
Oct 14 13:02:03: assistant reported full-frame diagnostic hashing alone consumed about 112 ms in a 4K test, while a nominal 10 ms step took 145–148 ms. This is a reported diagnostic-design/performance defect, not measured latency of ChatGPT itself.
Oct 14 19:23:35: assistant reported launch-to-first-recorded-AppKit-activity of 24.887 seconds in one build and 23.334 seconds in an older build. It also reported that the logger omitted menu-ready events in play mode. These are not exact launch-to-playable times and should not be presented as such.

The recurring acceptance gap is between component checks/artifact counts and actual integrated, usable, instruction-compliant delivery.

4. Misleading cancellation/availability signals and unfinished recovery

Oct 14 00:09:20: assistant disclosed gaps in the requested complete archive. At 00:11:06 it acknowledged not having checked an available signed-in-browser recovery route until the user pointed it out. Recovery subsequently archived 407 messages at 00:15:31; this was a recovered gap, not evidence of irretrievable loss.
Oct 14 00:13:29: assistant reported an upload returned “user cancelled”; user denied cancelling at 00:13:51. Retry succeeded at 00:15:31.
Oct 14 01:50:44: a second upload was reported as “user cancelled”; user again disputed it. Assistant reported successful retry at 01:54:29. No trace establishes whether the label originated in the service, review layer, or some other component.
Oct 14 00:57:32: assistant acknowledged that a browser panel was visibly open even though a task had called it unavailable; a failed tool attachment had been mistaken for absence of the browser.
Oct 14 19:33:36: assistant reported two cloud-browser approval-check timeouts followed by a browser connection timeout.
Oct 14 19:46:56: assistant reported a fresh tab opened, but no successful worker message had yet been verified. Opening a tab was correctly qualified as incomplete recovery, rather than successful end-to-end delivery.

Fresh browser recovery evidence

The detailed incident comment on #51103 records a later, directly observed sequence: obtaining the existing cloud browser initially failed approval at 20:39:03–20:39:09; the same operation succeeded after the original authorization was supplied at 20:39:38–20:39:43; attaching to the tab then returned a 20000ms CDP timeout at 20:39:46–20:40:11. Native UI access succeeded, a 20:40:27 screenshot showed “Aw, Snap! Error code: 9,” and clicking visible Reload restored readable task content by 20:40:46. Tab inventory and shell access remained usable. This restored page readability, not yet verified downstream message delivery. The initial approval stage is related to #51475; a shared cause with the technical timeout/crash is unproven.

5. Voice call failed while text coordination was already degraded

At 2026-10-14 20:34:45.279 UTC, the user reported that attempting a call displayed “can't connect the call.” At 20:34:59.915 the assistant responded in text and said it had not verified the cause.

This is a timestamped user-reported connection failure. The available record does not include a screenshot, exact client version, call identifier, transport trace, independently reproduced failure, or confirmed recovery. It must not be described as a proven service-wide voice outage, nor attributed to worker saturation or browser failure merely because those symptoms occurred in the same session.

Expected behavior and investigation requests

Preserve unfinished assignments across interruptions, monitor actual completion, and dispatch the next independent authorized task instead of relying on the user to notice inactive workers.
Keep the parent responsive while tool approvals, browser recovery, or workers are pending. Do not let a support-report task displace the original project silently.
Track current instructions and explicit supersessions through worker handoffs and receiving/release checks. Distinguish user restrictions from assistant-imposed temporary workflow limits.
Validate the installed artifact and real interaction against the user's acceptance criteria, not only passing unit tests, source readiness, a successful pipeline, or preview assets.
Report separate states for prepared, dispatched, received, running, complete, integrated, installed, and verified. A promise to send or an opened browser tab is not a successful handoff.
Make cancellation and connection errors diagnosable without incorrectly attributing them to the user. Add call-connection telemetry that can be correlated with the reported timestamp.
Investigate these as potentially interacting orchestration, tool/review, browser-attachment, instruction-propagation, and verification failures. The evidence does not support one universal root cause or weakening permission checks.

Additional incident: assigned research displaced by unsolicited email and personal-topic updates

Observed October 13–15, 2026, in a separate ongoing dot research conversation. All times below are UTC. Posted at the affected user's explicit request.

The user had repeatedly instructed dot to continue assigned research without waiting for another prompt. Instead, it sent unsolicited updates drawn from email and unrelated personal matters. The user states that this monitoring was never requested. The research stopped producing visible new substantive results, requiring another intervention.

Observed sequence

October 12: the user instructed dot to continue its previous work; research findings were delivered that evening.
October 13, 07:31–07:33: after the user asked for news, dot gave project status and an inconclusive check on an external dependency.
Until October 15, 15:36, the visible conversation then contains multiple unrelated email/personal-topic notices, but no further substantive findings from the assigned research.
October 15, 15:36: the user objected to unsolicited monitoring, requested this report, and reiterated that research should continue without further prompting.
Dot acknowledged the diversion, stopped unrelated tracking, and launched four parallel research investigations after that intervention. Launch is not a completed research result.
The user clarified that account-wide ChatGPT integrations must remain installed; any technical disconnection should be scoped to this dot only. No successful dot-specific access revocation is claimed.

The interval was approximately 56 hours. This is a gap in visible research results, not proof that every underlying task was inactive throughout it.

Impact

The assistant remained visibly active, but its activity no longer matched the assignment. The user had to supervise priorities and object to unrelated personal information being brought into the conversation. An unfinished task should not silently become general inbox monitoring merely because connected sources are available.

Expected behavior and regression checks

Preserve explicitly assigned research as the active responsibility. Continue actionable work within scope, or report a specific blocker and resumption condition.
Keep unrelated email and personal-topic monitoring outside that assignment unless requested. Connecting a source should not silently create a monitoring commitment.
When one direction awaits an external response, continue other independent authorized directions.
Honor an opt-out across subsequent continuations. Distinguish behavioral cessation from actual access revocation; support dot-scoped source controls without uninstalling integrations from the entire account.
Test an unfinished research assignment with incoming unrelated mailbox events: the assignment should retain priority, and opted-out topics should produce no monitoring notices.
Ground status in verified progress, blockers and delivered results rather than activity alone.

Evidence limits

Based on timestamped visible conversation and the assistant's acknowledgement. No backend scheduling, event-delivery or execution root cause is established. No post-correction opt-out violation is claimed. The current client build was not re-inspected; the original issue's historical version should not be assumed to apply.

Related: #50482 (prematurely stopping ongoing research) and #52209 (verifiable scoped stopping). Project details, email contents, correspondents, private links, account identifiers and financial information are omitted.

Follow-up: recurrence after the October 15 report

The same user-visible follow-through failure recurred on October 16, 2026, despite explicit instructions to continue the main research and use six available workers.

Observed timeline (UTC):

October 15, 22:09: the assistant told the user that the main research would continue in parallel with a narrowly scoped seller-reply check.
By approximately 22:13, the last research pass had completed. The user did not cancel the research.
October 16, 01:27: the user reported that the displayed agents were not doing work and that only two appeared in their UI. The screenshot has not been independently interpreted and is not attached here; the UI count is a user report, not a backend concurrency measurement.
The assistant acknowledged that completed checks had not been followed by new assignments, making its earlier statement of continuing parallel work inaccurate.
Only after this reminder, six distinct research assignments were launched between 01:27 and 01:28. A subsequent status check showed all six running. Launch is not evidence of completed research.

This is roughly three hours between completion of the last pass and the user's next intervention, following the earlier reported interruption. There were legitimate finite negative findings and evidence gaps; those do not justify claiming ongoing work when no research assignment is executing. If meaningful avenues are exhausted or blocked, the assistant should explain that accurately instead of implying continued execution.

Requested regression coverage:

Reconcile worker completion with the still-open parent task and the user's requested parallelism.
Keep 'actively researching', 'awaiting an external reply', and 'no actionable next step' visibly distinct.
Do not describe parallel continuation as active merely because the overall task remains open.
When six useful independent lanes are available and requested, dispatch them without requiring another user reminder. Do not fill slots with duplicate or make-work searches.
Preserve the main assignment while separately waiting on a narrow monitoring task.

The underlying cause remains unknown. This report documents the visible coordination failure and the verified restart, not a claim about scheduler internals or all Dots. No private correspondence, account details, project files, or screenshot are included.

Adding a narrower, separate observation about request-to-progress visibility in Dots desktop web. An AI-prepared report of one user's archived October case contains three inspected screenshots: an audit request, generation/thinking indicators, and a progress message, while the visible profile panel shows computer readiness, recent activity, and results without clearly identifying that audit. The panel has a more-activity control; no full task-detail capture is retained. The audit later produced artifacts. This supports a discoverability/state-mapping complaint, not a conclusion that execution stopped or that a parent wake event was lost.

A separate transcript episode records Morgan saying that a requested repair task was not created after cancellation, then reporting a later start. The cancellation's origin is unknown. We do not claim the approval or backend failure described in this issue was reproduced.

Could triage clarify the supported request-linked status surface and whether recent activity has documented freshness or completeness limits? Exact client build and internal task IDs are unavailable in the public evidence. Sanitized excerpts and an explicit evidence-limit table are included in the separate case report linked below. No raw conversation or private project URLs are attached.

Update, 20 October 2026: the full English field report and privacy-reviewed evidence pack are now publicly available at https://github.com/Goolagaccount/dots-field-report . They retain the scope and evidence limitations described above; no raw private conversation or screenshots are published.

Adding my experience as a Windows user: I tried Your dot expecting it to keep delegated work moving autonomously, but it stops too easily and leaves me having to supervise it and prompt it to continue. That supervision undermines the main reason I wanted to use an always-on assistant.

I would like Dot to follow through on the work already assigned, report genuine blockers clearly, and request my input when a decision actually needs me. I cannot establish whether my experience has the same technical cause as this report.

Could the OpenAI team confirm whether this follow-through problem is being investigated or fixed? Is there an estimated timeframe or target release for a correction?

Adding a related task-follow-through observation from my Dot on Mac, observed October 21, 2026 (Asia/Shanghai).

During ongoing delegated work, I repeatedly had to ask whether tasks were actually progressing and request the current state of the agents. The chat referred to seven agents and displayed an earlier status summary of seven working, but that summary is not independent execution evidence. After repeated prompts, Dot acknowledged that work had not continuously progressed to delivery and that acceptance checks, permission handling, and integration remained unfinished.

The practical failure is that I receive neither dependable progress/completion notifications nor a clear actionable blocker without repeatedly intervening. Requested 10-minute reports were missed; I have not verified that a real scheduled job was created. I also cannot establish from the conversation whether a worker-completion event was lost, approval was actually pending, or the parent stopped for another reason.

Expected: reconcile actual child-task state with the outstanding assignment, continue authorized actionable work, and proactively identify the precise blocker or completion result. Status should distinguish work running, awaiting approval, awaiting integration, and finished, with a last-updated time. Please confirm whether this follow-through behavior is under investigation and whether there is a supported recovery procedure that preserves the existing Dot and its tasks.

The separate conversational acknowledgement delays (five or six follow-ups receiving one response or none) are documented here: #54088 (comment) . I am reporting related user-visible symptoms, not claiming a shared proven root cause.

[Dots][macOS][Pro] Delegated work stalls after task completion or approval blocker; repeated reminders needed #49883

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

Relative execution timeline

What is the expected behavior?

Additional information

Native task read-back

Delegation / approval provenance seam

Messaging / connection evidence

Requested investigation / regression coverage

Duplicate review

Activity

github-actions commented on Oct 1, 2026

easyvibecoding commented on Oct 1, 2026

easyvibecoding commented on Oct 1, 2026

Thankyou-Cheems commented on Oct 1, 2026

aunysillyme commented on Oct 2, 2026

aetherxeg-source commented on Oct 2, 2026

pvillavi commented on Oct 11, 2026

leftbankvines commented on Oct 11, 2026

sora32127 commented on Oct 12, 2026

COOLak commented on Oct 14, 2026

Repeated delegated-work stalls, instruction drift, and a reported voice connection failure

Scope and evidence limits

1. Repeated handoff and worker-utilization failures

2. Latest user instructions were not consistently carried into execution

Reinterpreting small requests into the wrong work

Fresh communication-route instruction violation

Obsolete restrictions survived later authorization

A stated release requirement was omitted from the actual build

3. Checks and status claims did not always establish the user's actual outcome

4. Misleading cancellation/availability signals and unfinished recovery

Fresh browser recovery evidence

5. Voice call failed while text coordination was already degraded

Expected behavior and investigation requests

COOLak commented on Oct 15, 2026

Additional incident: assigned research displaced by unsolicited email and personal-topic updates

Observed sequence

Impact

Expected behavior and regression checks

Evidence limits

COOLak commented on Oct 16, 2026

Goolagaccount commented on Oct 16, 2026

antoniointini commented on Oct 19, 2026

NonTrivialLiu commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions