[Bug]: Oversized goal objectives surface as generic provider startup failures #23019

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Observed twice in a delegated Codex thread on 21 October 2026:

1. Complete work in an existing delegated thread.
2. Send a metadata-only follow-up through t3_thread_send beginning with /goal, followed by the complete work brief.
3. The two observed messages contain 6,360 and 5,305 JavaScript string characters, including the command prefix. Both exceed the provider objective limit.
4. Inspect the durable child timeline and server trace.

The second attempt shortened the brief but still exceeded the limit. No worker code executed on either attempt. I did not start another synthetic failing turn.

Expected behavior

Reject an oversized goal objective before dispatch, with its actual length and the supported limit. Preserve the brief for correction. The durable failure should identify the invalid input instead of suggesting transient provider setup trouble.

Do not silently truncate the objective or discard instructions. A short objective can refer to the full task record.

Actual behavior

Both child runs become terminal failed. The visible error says:

The provider could not start this turn. Retry the turn; if it keeps failing, check the provider setup and server logs.

The server trace identifies deterministic input rejection:

CodexAdapterV2.runGoalCommand
ProviderAdapterTurnStartError: Failed to start run [redacted]
[cause]: CodexAppServerRequestError: goal objective must be at most 4000 characters
[cause]: Error: goal objective must be at most 4000 characters

A generic retry cannot resolve an unchanged oversized objective. In this case it produced another failed run and led the parent to move a completed recording task to a fresh child context.

Impact

Minor bug or occasional failure. It causes avoidable repeated startup failures and child replacement during otherwise routine agent follow-ups.

Version or commit

T3 Code Nightly 0.1.2-nightly.20261021.3457.

Environment

macOS27.0.1, Codex provider, gpt-6.1-sol, codex-cli0.163.0.

Logs or stack traces

The two observed failures were at17:55:12.955Z and17:55:47.560Z. Sanitized cause above comes from server.trace.ndjson rotations. The child timeline contains only the generic provider-start error. No private task text, assets, credentials or thread identifiers are included here.

Workaround

Keep the goal objective below the provider limit. Put detailed instructions and evidence in an ordinary task message or an existing task-record reference. Preserve the current goal and delivery endpoint when separating the brief. Do not infer that a failed start requires regenerating completed artifacts or repeating completed reviews.

Bounded repair

Validate objective length at the owning goal-dispatch boundary and retain actionable protocol validation details in the durable terminal error. Cover the accepted boundary and oversized rejection with tests. Preserve existing authorization and full task content.