Windows Desktop: task messaging can use an unregistered host alias and report failure despite inconsistent delivery

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

Codex App 26.721.4979.0
Bundled app-server 0.146.0-alpha.3.1

What platform is your computer?

Windows 11 Home x64, version 10.0.26200, build 26200

What issue are you seeing?

Task-to-task messaging can be given a host ID that has no registered AppServerManager, even though the target is a local Codex task.

For the same target thread:

• the task list/delegation metadata reports a host shaped like slingshot:<redacted>
• reading the target thread resolves its host as local
• desktop logs show the app-server connection successfully started and connected for hostId=local
• sending with the host ID returned by the list/delegation metadata returns:

No AppServerManager registered for hostId: slingshot:<redacted>

The delivery outcome is also inconsistent with the response:

• for one send, the API returned the error above, but a later target-thread readback showed the packet had been delivered
• for another send with the same error, target-thread readback showed no delivery

This leaves the caller unable to determine whether retrying is safe. A retry can duplicate a packet that was delivered after an error response, while not retrying can lose a packet that was not delivered.

What steps can reproduce the bug?

1. Start Codex Desktop with local project tasks.
2. List the project tasks and select a target whose returned host ID is slingshot:<redacted>.
3. Read the same target thread and observe that its resolved host is local.
4. Send one task message using the host ID returned by the task list/delegation metadata.
5. Observe No AppServerManager registered for hostId: slingshot:<redacted>.
6. Read the target thread once.
7. The sent packet may be present despite the failure response, or absent.

What is the expected behavior?

• A local task should expose one canonical, routable host ID across list, delegation, read, and send APIs.
• Alternatively, the send path should normalize an alias to the registered local manager.
• A failed send response must not later produce an unreported side effect.
• A successful side effect should return a success/delivery receipt that is safe for callers to act on.
• If routing registration is still refreshing, the operation should wait for that transition or return a retry-safe status with a stable operation ID.

Additional information

The behavior may be a timing/race issue in host registration, task-list refresh, or send-result finalization: the error and later delivery can occur close together. This is a hypothesis, not confirmed root cause.

The local desktop logs show:

• Starting app-server connection hostId=local transport=stdio
• transport start success
• app-server connected for local

No registered manager for the returned slingshot:<redacted> alias was observed.

This seems related to #18556 and #28490 because of the same No AppServerManager registered family, but appears distinct:

• the affected targets are local project tasks rather than stale SSH targets
• two APIs disagree on the host identity for the same thread
• a send can take effect after returning an error, making the failure response non-transactional

Sanitized targeted logs can be provided if needed.