[Windows][dot] Cannot inspect and maintain an existing desktop automation end to end #54940

What version of the Codex App are you using?

Windows package 26.1013.4894.0; app-reported version 26.1013.40934; bundled CLI 0.163.0-alpha.10.2. Observed October 17, 2026.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Windows, with a connected computer authorized for dot tasks.

What issue are you seeing?

I asked my dot to help maintain an existing daily project check-in. It found an obsolete instruction about a meeting that had already happened. The needed cleanup was simply removing that bullet while preserving the rest of the task and its schedule.

The dot could read a previous run, but could not retrieve the current automation definition through the supported management path. Trying a genuinely local task got past the first error, but still did not provide the agent with the definition needed to safely prepare and verify the change.

This leaves me doing routine task administration myself. Based on the marketing and launch demonstrations, I expect my dot to help coordinate my agents, projects, and tasks. I should be able to give it a goal and approve any necessary changes without learning which conversation has the right execution context or manually carrying settings between conversations. A one-bullet cleanup should not turn into a troubleshooting exercise.

What steps can reproduce the bug?

Observed sequence on this installation:

1. Ask a dot to inspect an existing desktop automation so its instructions can be kept current.

2. The dot-created computer task can read a prior run through the supported native thread reader.

3. Calling native automation_update with mode: "view" and the existing automation ID fails with:

   Automations are only supported for local threads.

4. Create a fresh task through the supported native thread API. The returned metadata explicitly identifies hostId: "local".

5. In that local task, make the same read-only view request.

6. This time the call succeeds, but the only returned result is:

   Rendered automation card in the app.

   The response does not give the agent the current prompt, schedule, status, or other definition fields.

No automation update was attempted because we could not verify the authoritative definition and preserve the other settings. No automation was run, deleted, or recreated. No files, databases, host metadata, or permissions were changed to work around the restriction.

What is the expected behavior?

Provide an end-to-end, supported way for an authorized dot to:

• Read an existing desktop task's current instructions and settings.
• Propose a narrow change, such as removing an expired milestone.
• Apply the user-approved change while preserving its schedule and unrelated settings.
• Read back and verify the result.

A UI card can be useful for my approval, but the agent also needs enough structured information to prepare a safe edit and report whether it actually happened. If a particular route is intentionally unsupported, explain that and provide a supported handoff that carries the task context without making me reconstruct it.

I am not asking to bypass approvals or grant unrestricted access. I am asking for the assistant to complete ordinary management work within the permissions I give it.

Additional information

There are two observed boundaries here: the delegated task is rejected as non-local; the local task's successful view returns a UI-only acknowledgement rather than the definition. We have not established whether these are intended limitations or defects, or that the two have one root cause. The automation's scheduled execution is not reported as broken.

Related reports:

• Remote-created Codex Desktop threads on connected host do not receive automation_update/load_workspace_dependencies #24280: remote-created threads omit automation-management tools. In our delegated task the action was callable but rejected, and the local comparison exposed an additional readback gap.
• Codex Desktop: automation_update exposed in thread but rejected as non-local #25873: the exact non-local rejection; closed as a duplicate of Allow heartbeat automations from same-machine remote connection threads #24640.
• Allow heartbeat automations from same-machine remote connection threads #24640: same-machine remote automation access, closed for report-format/duplication reasons rather than a verified fix.

This report focuses on the remaining user workflow after testing a supported local task, rather than only whether a tool is listed. Please route or consolidate it if the full workflow is already tracked.

Private project names, automation IDs, account/device/thread identifiers, local paths, screenshots, and conversation contents are omitted.