Local automations vanish from Scheduled/Geplant panel after reinstall — client never queries them

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

Powered by Codex & OWL Version 26.915.31945

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After a fresh reinstall of Codex Desktop, locally-executed automations (execution_environment = "local", defined under %USERPROFILE%.codex\automations<id>\automation.toml) no longer appear in the "Scheduled"/"Geplant" panel. Only cloud-based automations are listed. This is not a display bug on top of a failed fetch — log analysis shows the client never even issues a request for local automations when the panel is opened. Local automations remain fully intact and continue executing on schedule in the background.

What steps can reproduce the bug?

1. Have several local automations configured and running normally (confirmed via memory.md timestamps updating on schedule, and SQLite WAL file (codex-dev.db-wal) actively written to at expected run times).
2. Fully uninstall and reinstall Codex Desktop (MSIX package).
3. Sign in again with the same account.
4. Open the Codex sidebar → "Scheduled"/"Geplant".
5. Observe: only cloud-scheduled tasks are listed; local automations are completely absent (not paused, not archived — simply not queried).

What is the expected behavior?

After reinstalling and signing back in, local automations present on disk under .codex\automations\ should be fetched and displayed in "Scheduled"/"Geplant", exactly as before the reinstall. Actual: only cloud automations are shown; local automations are silently never queried by the client.

Additional information

Environment
OS: Windows 11
Codex Desktop App (package OpenAI.Codex, MSIX): version 26.915.4065.0 (About dialog showed 26.915.31945 at time of report; package version differs due to MSIX numbering)
Codex CLI: codex-cli 0.155.0
CODEX_HOME: default, %USERPROFILE%.codex
config.toml: sandbox_mode = "workspace-write", [windows] sandbox = "elevated"
App reinstalled fresh (uninstall + reinstall) shortly before the issue appeared; fresh MSIX profile confirmed under %LOCALAPPDATA%\Packages\OpenAI.Codex_\LocalCache (created at reinstall timestamp)

What was ruled out (to save maintainers time)
Data layer intact: all automation.toml files present and valid (status = "ACTIVE", correct rrule, correct cwds).
Automations still execute on schedule post-reinstall — verified via memory.md mtimes matching expected run times, and active writes to codex-dev.db-wal at those times.
Codex CLI (codex in an interactive session) can see and use the same automations without issue.
windowsSandbox/readiness IPC calls succeed with errorCode=null throughout the session — not a sandbox/elevation problem. Confirmed by running the app fully elevated ("Run as administrator") — no change.
UI language switch (German ↔ "auto-detect" ↔ English) — tested repeatedly, no reliable effect on content (see note below).
Mode switch (Codex ↔ ChatGPT) — restores the "Geplant" sidebar entry's visibility in some cases, but never its local-automation content (cloud tasks only).
Full sign-out/sign-in, process kill (Stop-Process -Force on all Codex/ChatGPT processes), and system reboot — no change.
Terminal shell setting (PowerShell vs. Command Prompt) — no effect.
Checked config.toml trusted-projects / hooks — unrelated (separately confirmed and fixed a different, now-resolved issue: stale [hooks.state.*] trust hashes causing invalid transport in mcp_servers.codex_app, which is a distinct bug from this one).

Key log evidence

Captured response_routed IPC method names (method=...) from Desktop app logs (%LOCALAPPDATA%\Packages\OpenAI.Codex_\LocalCache\Local\Codex\Logs...) across a full session that included multiple visits to the "Geplant" panel:
account/login/start, account/logout, account/read, app/installed, app/read, chatgpt,
client-status-changed, collaborationMode/list, config/read, configRequirements/read,
experimentalFeature/list, externalAgentConfig/import/readHistories, fs/readDirectory,
fs/readFile, get, getAuthStatus, hooks/list, ipc-connection-reset, mcpServerStatus/list,
model/list, permissionProfile/list, plugin/installed, plugin/list, plugin/read,
query-cache-invalidate, remoteControl/enable, remoteControl/status/read, skills/list,
thread/attachment/list, thread/goal/get, thread/items/list, thread/list, thread/queue/list,
thread/read, thread/realtime/listVoices, thread/resume, thread/start, thread/turns/list,
thread-read-state-changed, thread-stream-following-changed,
thread-stream-following-status-requested, turn/start, windowsSandbox/readiness

No method related to automations, recurring tasks, schedules, or cron ever appears — not even one that fails or errors. This strongly suggests the client-side condition that decides whether to fetch local automations (likely tied to project/workspace state established at first run) evaluates incorrectly after a reinstall, so the fetch is never dispatched at all.

Related (but distinct) existing issues
#25393 — Automations sidebar badge/count disappears after update (cosmetic only, automations page itself remained usable). This report describes a more severe variant: the panel is usable but the local-automation content itself never loads.
#12679 / #21882 — No relink flow for a project whose path changed. Not applicable here — the project path is unchanged and confirmed valid (Test-Path → True).

codex-log-automation-hits.csv
codex-log-error-hits.csv

Reproduce the reinstall flow, then inspect the Desktop logs under %LOCALAPPDATA%\Packages\OpenAI.Codex_\LocalCache\Local\Codex\Logs\ while opening Scheduled/Geplant. Compare the automation.toml files under %USERPROFILE%.codex\automations\ with the recorded IPC methods and determine why no automation request is dispatched. Done means local automations are queried and displayed alongside cloud automations after reinstall.