Chrome plugin fails: app-server manifest entry missing required paths.parent

[bikindude]

Problem

The current ChatGPT/Codex Chrome Extension cannot start against the Linux wrapper-generated native host registration.

Chrome displays:

Unable to start ChatGPT
Codex app-server manifest entry is missing required path parent

This previously worked on the same machine and began failing after the recent Codex/Chrome plugin update.

Environment

• OS: Linux Mint 22.3, X11/Cinnamon, x86_64
• Installed package: codex-desktop 2026.07.17.070105
• Wrapper source version: 0.10.1
• Wrapper commit: b24e5ff2cfabbd1a366f711229b3b115aa4397fe
• Upstream app version: 26.715.21425
• Codex CLI: 0.144.6
• Chrome plugin version: 26.715.21425
• ChatGPT Chrome Extension: 1.2.27221.15725_0
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg

The wrapper was rebuilt/reinstalled through the supported make bootstrap-native process, but the error persists.

Verified generated state

The native messaging manifest exists and points to the bundled Linux host correctly:

~/.config/google-chrome/NativeMessagingHosts/com.openai.codexextension.json
→ ~/.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/linux/x64/extension-host

The extension is installed and enabled, and the native-host manifest allows the expected extension origin.

However, ~/.codex/chrome-native-hosts-v2.json contains this paths object:

{
  "browserClientPath": "~/.codex/plugins/cache/openai-bundled/chrome/latest/scripts/browser-client.mjs",
  "codexCliPath": "~/.codex/packages/standalone/releases/0.144.6-x86_64-unknown-linux-musl/bin/codex",
  "codexHome": "~/.codex",
  "extensionHostPath": "~/.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/linux/x64/extension-host",
  "nodePath": "/opt/codex-desktop/resources/node-runtime/bin/node",
  "nodeReplPath": "/opt/codex-desktop/resources/node_repl",
  "resourcesPath": "/opt/codex-desktop/resources"
}

There is no paths.parent field.

In addition, no extension-host-config.json is generated beside the extension host executable.

The bundled Chrome plugin's scripts/installManifest.mjs contains support for generating extension-host-config.json, but the Linux launcher's write_chrome_native_host_manifests() appears to generate only the browser native-messaging manifest. The wrapper-generated chrome-native-hosts-v2.json also lacks the newly required parent path.

Expected result

The Linux wrapper should generate the current Chrome plugin's full host configuration and a schema-compatible app-server registry entry, including the required paths.parent, so the extension host can start successfully.

Notes

Reinstalling the Web Store extension, reinstalling the bundled Chrome plugin, restarting Chrome/Codex, and rebuilding the latest local package did not resolve the failure. No generated manifest files were hand-edited.

[psypeal]

Thanks for the detailed report. I reproduced this same failure family locally.

One clarification: parent is not a required JSON key under paths. The message Codex app-server manifest entry is missing required path parent is emitted when the native host rejects a filesystem parent in the trust chain for one of the registered paths. In my reproduction, the bundled Chrome plugin cache was rematerialized under a cooperative umask 0002, leaving group-writable (0775) directories that the native host correctly rejected.

Closed PR #1026 addressed this bundled-plugin cache materialization boundary. It was closed because of the repository's one-active-PR-per-contributor limit, not because the underlying issue was resolved.

I have #1080 open now, so I will not open another PR yet. After #1080 is closed, I plan to rebase a focused replacement for #1026 onto the latest main, link it to this issue, and include regression coverage for reinstalling over an existing 0775 cache/staging tree. The fix should harden the actual filesystem materialization path rather than add a synthetic paths.parent field.

[ilysenko]

Thank you for the detailed report. I am working on a safe fix.

parent is not a missing JSON field. The native host emits this error when a filesystem parent in a registered runtime path fails its trust checks. PR #1026 was not safe because its post-copy permission normalization could make an untrusted source tree appear trusted after the files had already been copied.

The fix must validate the canonical bundled source, its ancestor chain, and its complete tree before copying; create a private 0700 staging root; reject unsafe ownership, symlinks, and group/world-writable paths; and fail closed.