macOS: artifact-tool import fails because skia.node and node_repl have different Team IDs

Open 💬 1 comment Opened Jul 24, 2026 by jekalih

Summary

The approved ChatGPT/Codex desktop spreadsheet runtime cannot import @oai/artifact-tool on macOS because its bundled native skia.node module has an incompatible signing identity with the OpenAI-signed hardened execution host.

In-product feedback was also submitted without logs. Feedback thread ID: 019f9175-e903-7473-8905-3990e8bc3bfa.

Environment

ChatGPT/Codex app version: 26.715.70719
App build: 5650
Workspace runtime bundle: 26.715.12143
node_repl hardened runtime: 26.5.0
@oai/artifact-tool: 2.8.24
skia-canvas: 3.0.8
Mac architecture: ARM64

Execution host

/Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node_repl

OpenAI Team ID: 2DC432GLL2
Hardened runtime enabled
Signature verification passes
Does not contain the com.apple.security.cs.disable-library-validation entitlement

Failing native module

/Users/scorcher/.cache/codex-runtimes/codex-primary-runtime/dependencies/node/node_modules/.pnpm/@oai+artifact-tool@file+local-deps+-oai-artifact-tool-oai-artifact_tool-2.8.24.tgz/node_modules/@oai/artifact-tool/node_modules/skia-canvas/lib/skia.node

Identifier: libskia_canvas.dylib
Ad-hoc/linker-signed
No Team ID
Signature verification passes independently

Reproduction

Run inside the required node_repl host after registering the approved workspace dependency node_modules directory:

var approvedArtifactToolImport = await import("@oai/artifact-tool");

macOS reports:

code signature ... not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs

The complete dlopen error identifies the skia.node path above and repeats the different-Team-IDs failure for both attempted non-Cryptex paths.

Verified exclusions

Architecture mismatch: ruled out; host and module are ARM64
Damaged signature: ruled out; strict signature verification passes
Quarantine: ruled out
Missing dependency: ruled out
Corrupted installation: no evidence
Reinstalling the official app restored the same affected app and runtime versions and produced the identical failure

Relevant hashes

node_repl SHA-256: b2ccfc60722ef09569b2038e60bcef8fef7240fd550651a9d808c6a12a354618
skia.node SHA-256: 05721a911d979194b5346d7f80b0809f2d16d74de5ffc3831da4e67e2ca6eef9

Expected resolution

Please route this to the desktop/Codex runtime engineering team. It appears to require an official runtime package where skia.node is signed compatibly with OpenAI Team ID 2DC432GLL2, or another officially supported packaging correction. Please confirm when a corrected desktop build or workspace runtime bundle is available.

View original on GitHub ↗

1 Comment

ninjai · 29 days ago

Confirmed that this still reproduces on a newer Desktop/runtime combination and
on Intel macOS:

ChatGPT/Codex Desktop 26.721.81911 (build 5973)
Bundled codex-cli 0.146.0-alpha.3.1
Primary runtime bundle 26.727.11326
Runtime manifest artifact-tool 2.8.31
Installed @oai/artifact-tool 2.8.33
skia-canvas 3.0.8
macOS 13.7.8, x86_64

The newer x86_64 runtime copy of skia.node is completely unsigned rather than
linker/ad-hoc signed:

code object is not signed at all

Its SHA-256 is
8178acf1a69814779d124675502c0ae08868eb190dcc28ea735d0294f8c45d38.
I downloaded the official upstream skia-canvas v3.0.8
darwin-x64.gz; after decompression, its SHA-256 is identical, so this is not
local corruption or signature stripping during the Codex runtime installation.

The updated Desktop app passes deep/strict signature verification. With the
same NODE_PATH:

ChatGPT.app/Contents/Resources/cua_node/bin/node fails with

ERR_DLOPEN_FAILED, mapped file has no cdhash, completely unsigned.

The primary runtime's own Node succeeds and imports artifact-tool

(1171 exports).

The Desktop Node does not have
com.apple.security.cs.disable-library-validation; the runtime Node does. This
confirms the same Library Validation boundary reported here and shows that the
problem persists across newer builds and both macOS architectures.

No app, runtime, entitlement, or native-module signature was modified during
the test. Full duplicate report and reproduction details were posted in #36009;
I am closing that issue in favor of this one.