Dot acknowledges child-agent Goal requests but creates only ordinary messages #54028

Summary

When I ask my Dot to set a persistent Codex Goal for an agent that Dot created, Dot acknowledges the request but appears to send the child an ordinary follow-up message instead of creating a native Goal. The child then performs some tool work, but there is no persistent Goal attached to the child thread and it does not reliably continue toward the requested outcome.

If I open the child task manually and try to create a Goal through the Goal UI, the operation fails with a usage-limit error even when the account still has substantial usage remaining. The UI does not explain that the request is unsupported, that the Goal was never created, or that Dot or another control surface is required.

This report concerns the Dot-to-Codex delegated-agent workflow. It is separate from ordinary one-thread Goal creation.

Environment

• Product: ChatGPT Dot creating or delegating to a Codex agent
• Platform: Windows desktop app with a connected Windows computer
• Account plan: ChatGPT Pro
• Repository/runtime involved: OpenAI Codex / multi-agent delegated thread
• Exact Dot and Codex build numbers: not captured in the reproduction
• Usage state during the failure: below the account usage limit; the reported error did not match the observed usage state

Reproduction

1. Create or use a Dot with access to create Codex or Work tasks.

2. Ask the Dot to create an agent for a concrete task.

3. After the child agent exists, tell the Dot explicitly:

   Set a persistent Goal for the agent you created. Keep working on that Goal until the task is complete, and use the Goal lifecycle rather than sending an ordinary message.

4. Dot acknowledges the instruction.

5. Inspect the child task and its activity.

6. Observe that Dot has sent a normal message or follow-up, but no native Codex Goal has been created for the child thread.

7. Open the child task manually and use the Goal UI to create the Goal.

8. Observe a usage-limit error, despite remaining account usage and no matching usage exhaustion.

Actual behavior

Two failures occur:

1. Dot does not perform the requested Goal mutation. It acknowledges the request but sends an ordinary message to the child instead of calling the native Goal lifecycle.
2. Manual Goal creation on the child fails with a misleading usage-limit error. The error does not distinguish between quota exhaustion, an unsupported child-thread mutation, a missing control path, or a backend failure.

The child may still run tools after receiving the ordinary message, but tool activity is not evidence that a persistent Goal exists. When the current turn ends, the child does not reliably continue working toward the requested completion criteria.

Expected behavior

When the user explicitly asks Dot to set a Goal for a child it created:

• Dot should create or update the native persistent Goal on the correct child thread.
• The child should receive the objective, completion criteria, constraints, token budget, and lifecycle state through the Goal mechanism.
• The Goal should appear in the child task's Goal UI and remain attached across turns and resumes.
• Dot should verify the mutation succeeded, for example by reading the resulting Goal state, instead of reporting success after sending only a normal message.
• If Dot cannot control that child Goal, it should say so clearly and report the actual reason.
• Manual Goal UI failures should report the real cause. A parent-owned or unsupported mutation must not be labeled as a usage-limit failure.
• Goal status and usage accounting should remain consistent between Dot, the child task, and the Codex UI.

Why this matters

The Dot documentation describes Dot as an always-on agent that can create Codex tasks and continue work between conversations. Acknowledging a Goal request without creating the persistent Goal makes the workflow look successful while silently degrading it to an ordinary one-shot instruction.

The current behavior also prevents recovery: Dot does not create the Goal, while manually creating it in the child produces a misleading quota error. The user cannot tell whether the Goal exists, whether Dot has permission to manage it, or whether the account is actually out of usage.

Requested investigation

Please trace the complete path:

1. Dot's interpretation of a request to set a Goal on an already-created child task.
2. The tool or API call used to send the child follow-up.
3. Whether Dot has access to the native create_goal, get_goal, update_goal, pause, resume, and clear lifecycle operations.
4. The mapping between Dot-created tasks and Codex thread IDs.
5. Authorization for a parent or Dot to mutate the Goal of its own child while preventing unrelated clients or the child from mutating protected state.
6. The error path that converts the failed child Goal mutation into a usage-limit message.
7. Verification that Goal state persists and automatic continuation resumes at the intended idle boundaries.

Suggested acceptance tests

• Ask Dot to create a child task and set a Goal. Verify that get_goal on the child returns the requested objective and an active status.
• Ask Dot to replace, pause, resume, and clear that child Goal. Verify each state transition in both Dot and Codex.
• Ask Dot to set a Goal after the child has already run tools. Verify the Goal is attached to the existing child rather than creating only a new message.
• Make the child idle after a tool call. Verify an active Goal causes supported continuation until completion, a real blocker, an explicit pause, or a genuine budget limit.
• Attempt the same mutation from an unrelated thread and from the child itself. Verify it is rejected with a precise authorization error.
• Simulate insufficient usage and compare the error with the parent-owned or unsupported-thread case. Verify they are distinguishable.
• Verify that a failed Goal mutation never produces a success acknowledgment from Dot.

Related reports

• Delegated agents lose local Docker access and report false usage-limit errors for goals #54023: delegated agents report false usage-limit errors and lose expected local capabilities
• Improve dot’s end-to-end agent capabilities across existing Codex sessions, desktop control, and remote MCP tools #49492: Improve Dot's end-to-end agent capabilities across existing Codex sessions
• Expose Goal controls outside the interactive TUI, both for external automation and agent-side workflows. #31783: Expose Goal controls outside the interactive TUI
• [Codex App][Goals] File-backed Goal prematurely completes after reading goal-objective.md instead of executing the actual task #53814: file-backed Goal prematurely completes after reading the objective file

No private task IDs, credentials, local paths, or private project contents are included. Redacted screenshots and exact build numbers can be provided if needed.