[icesixgod]

The native trajectory viewer could remain on “Waiting for trajectory data” even after show_codex_trajectory succeeded: it never initialized the MCP Apps bridge, and late openai:set_globals events ignored toolOutput.

Complete the ui/initialize / ui/notifications/initialized handshake and render delayed legacy results. Rejected, unsupported, or timed-out initialization shows a recoverable error only while no trajectory has rendered. Existing initial-global and direct-notification delivery paths remain supported. No log access, full-detail permissions, or CDP settings change.

Validation:

• Reproduced handshake and delayed-global failures before the fix; existing delivery paths passed.
• 8 startup browser regression cases pass, including rejection, unsupported versions, timeout recovery, and existing-data preservation.
• GitHub CI: all 15 checks pass. Browser UI and CDP transport: 75 passed; runtime matrix passes on Linux, macOS, and Windows with Python 3.10, 3.12, 3.13, and 3.14.
• Python suite: 361 passed, 57 skipped; 84.45% coverage.
• Ruff formatting/lint, mypy (native and Windows), release metadata validation, and packaged MCP stdio smoke pass.

The actual Codex desktop surface cannot be inspected through the available computer-use tool. This fixes the reproduced component defects; it does not claim to prove that a missing host tool card has no additional cause. The currently installed plugin cache is unchanged.