Spreadsheet runtime unavailable in scheduled Codex tasks on Windows

Open 💬 2 comments Opened Jul 16, 2026 by JerryCodez
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.91948

What subscription do you have?

Plus

What platform is your computer?

Win 11 Pro

What issue are you seeing?

Feedback ID: 019f6be5-03ee-7ea0-bc04-dc9618e51b64

Hello OpenAI Team,
I would like to report a reproducible issue with the Spreadsheet plugin in scheduled Codex tasks.
Problem description:
My custom “ETF Analyzer” skill analyzes a local XLSX file. When the skill runs in a regular interactive Codex task, it can access the Spreadsheet runtime, including load_workspace_dependencies and @oai/artifact-tool, without any issues.
When the same skill runs through a local scheduled task, load_workspace_dependencies is unavailable. As a result, @oai/artifact-tool cannot be loaded and the XLSX file cannot be processed normally.
The issue also occurs when the scheduled task is started manually using “Run now.”

Steps to reproduce:
Create a skill that analyzes a local XLSX file using the Spreadsheet plugin.
Run the skill in a regular interactive Codex task.
Confirm that load_workspace_dependencies and @oai/artifact-tool are available.
Run the same skill through a local scheduled task.
The scheduled task reports that load_workspace_dependencies is unavailable.

What steps can reproduce the bug?

Feedback ID: 019f6be5-03ee-7ea0-bc04-dc9618e51b64

What is the expected behavior?

Expected behavior:
Local scheduled tasks should be able to access enabled plugin tools. The skill should receive the same Spreadsheet runtime that is available during a regular interactive execution.

Additional information

Actual behavior:
The skill itself is loaded, but the associated Spreadsheet loader is missing exclusively during scheduled-task execution. Consequently, the workbook cannot be imported or modified using @oai/artifact-tool.

Environment:

  • Operating system: Windows
  • Execution type: Local scheduled task in the Codex desktop app
  • Automation ID: etf-allokation-vergleichen
  • Feedback/session ID: 019f6be5-03ee-7ea0-bc04-dc9618e51b64
  • Plugin: spreadsheets@openai-primary-runtime
  • Plugin version: 26.715.12143
  • Missing tool: load_workspace_dependencies
  • Affected library: @oai/artifact-tool
  • Regular interactive skill execution: Works
  • Automatic and manually triggered scheduled-task execution: Does not work

As a temporary workaround, I am using a custom read-only OOXML fallback for the analysis. For safety reasons, this workaround cannot perform write operations.

Could you please investigate why the Spreadsheet runtime is not being provided to local scheduled tasks?

Thank you.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33503
  • #33619

Powered by Codex Action

JerryCodez · 1 month ago

Update after testing a genuine scheduler-triggered run:

The scheduled execution completed successfully and received the Spreadsheet runtime, including load_workspace_dependencies and @oai/artifact-tool.

The failure occurs only when the same automation is started manually through the Codex Desktop “Run now” action. In that execution path, the skill is available, but the required Spreadsheet runtime tools are missing.

Updated behavior:

  • Regular interactive task: works
  • Genuine scheduler-triggered automation run: works
  • Desktop “Run now” automation run: fails because load_workspace_dependencies is unavailable

This matches the behavior reported in #33503: the desktop “Run now” path creates a task with an incomplete tool manifest, while scheduler-triggered runs receive the full tool suite.

Therefore, this issue appears to be a Spreadsheet-specific manifestation of #33503 rather than a general failure of scheduled tasks. The title and original description of this issue were too broad because my earlier tests used “Run now” while the automation itself was paused.