Spreadsheets plugin cannot access load_workspace_dependencies in Codex CLI

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #34270
• #34091

Powered by Codex Action

Additional controlled comparison:

On the same Windows machine and with the same primary runtime bundle
26.715.12143, Codex Desktop successfully exposes and invokes the namespaced
tool codex_app__load_workspace_dependencies.

The returned bundled Node v24.14.0 runs successfully, the returned
node_modules directory is accessible, and @oai/artifact-tool imports
successfully as an ES module.

Codex CLI 0.145.0 reports workspace_dependencies as stable/true and loads
the same enabled Spreadsheets plugin, but exposes neither
load_workspace_dependencies nor a namespaced equivalent.

This strongly suggests a CLI host-tool registration or surface integration
gap rather than a damaged runtime bundle, missing package, sandbox denial,
or third-party process interference.

Same issue on Mac.

Reproduced on macOS 14.8.3 (Apple Silicon) through an OpenClaw-hosted Codex session.

Environment/results:

• Codex CLI 0.144.3: Spreadsheets plugin is installed and enabled, but load_workspace_dependencies is absent from the session tool catalog.
• Fresh isolated Codex CLI 0.145.0 session: same result; the loader is still absent.
• Enabling the relevant workspace-dependency/artifact settings and starting fresh sessions did not expose the tool.
• The bundled primary runtime and @oai/artifact-tool are physically present and functional.

To separate runtime health from tool registration, I invoked the bundled runtime using its own Node executable and dependency tree. A disposable canary successfully:

1. created a workbook,
2. evaluated a formula,
3. rendered a PNG preview,
4. exported a valid XLSX, and
5. passed ZIP/XML validation.

This suggests the failure is in host/session tool registration rather than a missing or broken artifact library. The generic external Node route could not load the bundled Skia native module on macOS because of native-module signing compatibility, but the runtime own Node route worked.

One possibly relevant inconsistency: the runtime manifest listed artifact-tool 2.8.23 while the installed package identified itself as 2.8.31.

No manual npm installation was needed. A supported fix would appear to require exposing load_workspace_dependencies to the active session (or otherwise providing the plugin the approved runtime/dependency paths).

Additional Codex Desktop reproduction (Windows 11)

I can reproduce the same missing-tool failure in an interactive Codex Desktop task.

Environment

• Windows 11 Pro 64-bit (10.0.26200)
• Codex Desktop package: 26.721.4979.0
• Spreadsheets plugin/skill: 26.723.12215
• Interactive Desktop task (not a scheduled or remote task)

Observed behavior

• The Spreadsheets skill is installed and readable.
• After a complete Codex app restart, load_workspace_dependencies is still absent from the task's callable tool catalog.
• An exact deferred-tool search returns zero loader matches.
• A direct runtime check returns typeof tools.load_workspace_dependencies === "undefined".
• Node execution is available, but the approved loader that should return the bundled Node executable and node_modules path is not registered.
• Consequently, @oai/artifact-tool cannot be loaded through the required path, and standalone .xlsx authoring cannot begin.

The restart did not change the tool manifest. No guessed dependency paths, package installations, resolution hacks, or alternative spreadsheet libraries were used.

Expected behavior
When the Spreadsheets plugin is installed and enabled in Codex Desktop, the task should expose load_workspace_dependencies so the supported artifact runtime can be loaded.

This appears to be a Desktop task tool-registration/injection failure matching the CLI symptom reported here. I can provide the task or feedback ID privately if a maintainer needs it.

It is recommended to check config.toml (line 46), [mcp_servers.node_repl] and [mcp_servers.node_repl.env] to see if the deprecated Codex.app path has been introduced.

Same issue

Controlled Windows follow-up: node_repl path hypothesis ruled out

I reproduced the missing loader on the current Windows Desktop and CLI builds and tested the config.toml / node_repl suggestion above without modifying the persistent configuration.

Environment

• Codex Desktop package: 26.721.4979.0
• Desktop app-server CLI: 0.146.0-alpha.3.1; standalone CLI: 0.146.0
• Spreadsheets plugin: 26.727.11326, installed and enabled
• Primary runtime: 26.727.11326
• Runtime Node: v24.14.0; @oai/artifact-tool: 2.8.31
• workspace_dependencies and skill_mcp_dependency_install: stable / enabled

Controlled results

• No deprecated /Applications/Codex.app/... literal is present in this Windows configuration.
• The configured %LOCALAPPDATA%\OpenAI\Codex\... node_repl, Node, and Codex executables all exist and are the current Desktop-managed copies. Their SHA-256 hashes match the corresponding installed Store-package resources byte-for-byte:
• node_repl.exe: 2FCF3EC7...50CEAE2D
• node.exe: 63C259C8...9048088
• codex.exe: 39E9E041...352A6EF3
• A minimal node_repl JavaScript call succeeds.
• A fresh ephemeral A/B run with -c 'mcp_servers.node_repl.enabled=false' still reports: ABSENT: load_workspace_dependencies is not present in the callable tool registry.
• A fresh Desktop project chat after a full restart returns TypeError: tools.load_workspace_dependencies is not a function.
• A retained call where the schema was advertised reached dispatch but returned No handler registered for tool: load_workspace_dependencies.
• The primary runtime diagnoses as installed=true with problemCount=0.

This rules out a stale/deprecated node_repl path on this host and continues to point to host/session tool registration. No dependency paths were guessed, no packages were installed, and no alternate spreadsheet library was used.

I also submitted Codex feedback with the diagnostic session and Desktop log. Feedback thread ID: 019fb14c-97e3-76e0-864d-5d776b2f68c0. The feedback upload succeeded; only its optional doctor-report attachment timed out and was skipped.

macOS reproduction on newer CLI and plugin versions (August 4, 2026)

I can reproduce this on a current macOS Apple Silicon environment with newer versions than the original report:

• macOS 26.5.2 (Darwin 25.5.0, arm64)
• Codex CLI: 0.146.0
• Spreadsheets plugin: 26.802.11031 (installed and enabled)
• workspace_dependencies: stable / true

Observed behavior:

1. The active Codex session tool catalog still does not expose load_workspace_dependencies or a namespaced equivalent.
2. A Node REPL is available, but the exact import required by the Spreadsheets skill fails:

Module not found: @oai/artifact-tool

1. The installed Spreadsheets skill explicitly requires the loader-provided Node executable and node_modules directory. Without the loader, standalone XLSX authoring cannot proceed without violating the supported runtime contract.

Expected behavior:

When the Spreadsheets plugin is installed and enabled and workspace_dependencies=true, a new Codex CLI session should register load_workspace_dependencies and return a dependency directory containing an importable @oai/artifact-tool.

This confirms that the issue remains unresolved with Codex CLI 0.146.0 and Spreadsheets plugin 26.802.11031 on macOS. Please prioritize the host tool-registration or runtime-version compatibility fix, since the plugin is presented as available while its mandatory runtime path is unusable.

No packages were installed, no dependency paths were guessed, and no alternate spreadsheet library was used during validation.