[macOS] Visualize 1.0.16 materializes live-disabled and does not register the native path

[johnsilvavlogs]

[macOS] Visualize 1.0.16 materializes the live-disabled variant and does not register the native visualization path

Codex App bug-template fields

• What version of the Codex App are you using? 26.727.40816 (build 6067)
• What subscription do you have? ChatGPT subscription; exact tier is not exposed by codex login status
• What platform is your computer? Darwin 25.5.0 arm64 arm

Suggested labels

bug, app, skills

Environment

• Codex Desktop: 26.727.40816 (build 6067)
• Platform: macOS
• Bundled plugin: visualize@openai-bundled 1.0.16
• User configuration: Visualize is enabled

Summary

On this build, the bundled Visualize plugin is enabled but its installed runtime materializes a live-disabled content variant. A fresh native-capability check then finds no native Visualize registration. The Plugins UI's Try now affordance launches a task carrying the native plugin chip, but that task reports that the Visualize skill was omitted and then compensates by manually writing two-value-explorer.html and emitting the generic ::codex-inline-vis directive. This makes the product appear available while the live/native route is absent.

This is not the renderer-path problem in #32054, the helper-path documentation problem in #35211, or the standalone-HTML routing problem in #33164: the failing boundary here is bundled-plugin materialization/registration for the current app build.

Reproduction

1. Install Codex Desktop 26.727.40816 (build 6067) on macOS.
2. Confirm that visualize@openai-bundled is enabled in Codex configuration.
3. Start a fresh Codex task so the tool/skill surface is discovered anew.
4. Inspect the installed Visualize cache manifest and the runtime materialization state.
5. Run the normal fresh native-capability discovery for Visualize.
6. In the Plugins UI, select Visualize and use Try now.

Actual behavior

• The materialization key is liveVisualizationSkillVariant=live-disabled.
• The installed cache manifest records bundledContentVariant=live-disabled.
• Production feature dispatch contains visualizeLive:false.
• Fresh native discovery is absent-after-discovery: no native Visualize registration is exposed.
• The task launched by Try now carries the plugin chip but reports that the native skill was omitted; its agent then manually writes two-value-explorer.html and emits generic ::codex-inline-vis instead of invoking a registered native Visualize skill.

Expected behavior

With Visualize enabled, the shipped app should materialize the variant intended for its live/native experience, register that capability in a fresh task, and make Try now exercise the same supported path. In particular:

• the effective materialization key and cached manifest must agree with the enabled live/native feature;
• production dispatch must not leave the enabled plugin behind visualizeLive:false;
• fresh discovery must expose the native capability when the product presents Visualize as enabled; and
• Try now should be a native-path canary, not a separate manual HTML/directive fallback that can succeed while native registration is absent.

Evidence and integrity controls

All filesystem locations below are intentionally generalized (<CODEX_HOME>, <APP_BUNDLE>) to avoid disclosing user-specific paths.

Evidence layer	Observed value
Configuration	Visualize enabled
Materialization key	liveVisualizationSkillVariant=live-disabled
Installed cache manifest	bundledContentVariant=live-disabled
Production feature dispatch	visualizeLive:false
Fresh-task native discovery	absent-after-discovery
Native UI canary provenance	Plugins UI -> Visualize -> Try now launches native-chip task -> task reports skill omitted -> agent manually writes two-value-explorer.html + generic ::codex-inline-vis
Version anchor	app 26.727.40816 build 6067; plugin 1.0.16

The evidence was cross-checked across the enabled configuration, materialization key, cached plugin manifest, production dispatch, a fresh discovery surface, and the first-party Plugins UI. It therefore does not rely solely on a stale thread, a single cache directory, or agent interpretation of a prompt response.

Why reinstalling the same build or clearing cache is not a supported repair

The failing values originate in the current build's materialization/feature-selection path: the enabled configuration, live-disabled materialization key, cache manifest variant, and production visualizeLive:false all agree. Reinstalling the same build or clearing the cache would merely rematerialize the same selected variant; it does not change the build-provided feature dispatch or create a missing native registration. Users should not need to mutate caches or patch bundled assets to make an enabled first-party plugin work.

Requested repair

1. Audit the macOS 26.727.40816 bundled Visualize release inputs so an enabled Visualize plugin selects and materializes the intended live/native variant.
2. Make registration and availability derive from one authoritative variant/feature decision; reject or visibly diagnose contradictory states such as “enabled in UI/config” plus live-disabled plus no native registration.
3. Make the Plugins Try now flow invoke the registered native path, and show a clear unsupported/unavailable state if it is not registered. Do not silently substitute a generic inline-HTML example.
4. Add release coverage that starts a fresh task and asserts: enabled config -> expected manifest/materialization variant -> enabled production dispatch -> discoverable native Visualize capability -> Try now exercises that same capability.
5. Surface a user-actionable diagnostic in the plugin UI when the bundle is intentionally live-disabled, including the effective variant and reason.

Related, but not duplicates

• #35211 — Visualize helper-path documentation is wrong; it assumes Visualize is already installed/materialized.
• #36100 — bundled-plugin content-variant reconciliation mismatch causing startup delay; related variant machinery, but different symptom and plugins.
• #21936 — stale bundled marketplace cache hides Chrome on macOS.
• #21138 — cache refresh can retain stale bundled/local contents without a version bump.
• #25990 — resumed threads can retain stale dynamic tool metadata; this report includes a fresh-task control and is about Visualize materialization/registration.
• #32054 — renderer reads a different visualization directory.
• #33164 — Visualize over-triggers for standalone HTML.

Duplicate search decision

No exact duplicate found as of 2026-07-30. I searched openai/codex issues and pull requests by Visualize, visualization, Try now, codex-inline-vis, two-value-explorer, live-disabled, and native registration, then inspected the closest Visualize, cache, and dynamic-tool reports listed above. Those reports cover adjacent documentation, path resolution, cache freshness, marketplace visibility, reconciliation performance, or stale thread metadata—not an enabled Visualize live-disabled materialization paired with fresh native absence and a non-native Try now route.

[johnsilvavlogs]

Additional controlled local evidence after filing:

• I backed up both generated Visualize trees, then removed only bundledContentVariant from the generated marketplace manifest and the installed cache manifest. No signed app or bundled app content was modified.
• I launched a new projectless native-only task and explicitly prohibited the local fallback and manual ::codex-inline-vis output.
• The fresh task still classified native Visualize as absent-after-discovery: there was no visible skill and no exact deferred registry match, so native invocation could not begin.
• Neither generated manifest was rewritten during the canary. I then restored both manifests exactly from backup; the two live files and two backup files all match SHA-256 a6944391eafad278a811b6cbb1ccf56d3507735b29bdc6b15ec164a4be38d575.

This falsifies a manifest-field-only workaround. The bundledContentVariant field is downstream evidence of the selected production state; removing it does not change native registration. The production visualizeLive:false / materialization decision remains the smallest supported owning boundary.

As a separate control, an explicitly invoked user-installed temporary copy of the Visualize skill rendered real interactive controls in Codex: changing A=4 and B=5 updated Sum to 9, and restoring A=1 and B=2 restored Sum to 3. That confirms the inline renderer and interaction transport are healthy, but it remains a fallback and does not satisfy the bundled native path.

I also rechecked the official appcast: 26.727.40816 build 6067 is still the latest macOS arm64 item, and the current signed app passes strict codesign plus Gatekeeper assessment. There is therefore no newer official build to test yet and no safe signed-integrity-preserving native patch at the downstream manifest boundary.