Desktop plugin toggle leaves live thread on stale hook engine after upgrade

What variant of Codex are you using?

Codex Desktop on macOS.

Which version are you using?

codex-cli 0.146.0-alpha.9.2

Bug description

After installing a newer version of an enabled marketplace plugin, the existing Desktop thread resolved skills from the new immutable plugin cache but continued executing hooks from the former plugin version. Disabling and re-enabling the plugin in Desktop did not replace the live thread hook engine.

This is a split runtime: model-visible skills and lifecycle hooks come from different releases in the same thread.

Related capability request: #17636.

Steps to reproduce

1. Start a Desktop thread with an enabled plugin whose hook manifest runs exact version-pinned commands. In this reproduction the active version was 0.70.0.
2. Install version 0.71.0-rc.0 of that plugin through its configured marketplace without closing the thread or restarting Desktop.
3. In the same thread, confirm an explicitly invoked plugin skill resolves from the immutable 0.71.0-rc.0 cache root.
4. Trigger a hook event and observe that the running hook still reports 0.70.0.
5. Open Desktop Plugins, disable the plugin, then enable it again.
6. Return to the unchanged thread and trigger UserPromptSubmit, PreToolUse, and PostToolUse.

Expected behavior

The native disable/re-enable operation should atomically refresh all plugin capabilities for the live thread, or explicitly report that a new thread is required. Skills and hooks should never silently resolve from different plugin releases.

Actual behavior

The thread ID remained unchanged and skills continued resolving from 0.71.0-rc.0, but all three fresh hook events executed 0.70.0.

Old hook manifest SHA-256:
09fc3c9b2884d0f129c57faf96b632afdebeaf88d72ba4e1ecd397f665edbcd2

Expected candidate hook manifest SHA-256:
67955adc0c39d80788c39e555015562a6831e1bead0ab0694bf3f36a9b64331b

The fresh events were recorded after the Desktop toggle, so this was not an inventory-only observation or a stale proof file.

Additional information

Current core source has a refresh_runtime_config path that rebuilds hooks and transactionally replaces the stored hook registry. The observed Desktop behavior suggests the plugin toggle either does not invoke that refresh for the owning thread or rebuilds against stale plugin state.

A safe resolution would make plugin enablement changes atomically refresh both skills and hooks in existing threads. If that is intentionally unsupported, Desktop should keep the old complete bundle active and clearly direct the user to start a new thread instead of exposing a split state.