Codex scheduled automation returns exit 134 when invoking Obsidian CLI, while the same command works in an interactive Codex chat

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

26.305.950 (CFBundleVersion 863)

What subscription do you have?

chatgpt plus

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

When a Codex desktop automation runs on its schedule, commands that invoke the Obsidian CLI can fail with exit code 134.

In my case, the automation is a recurring workflow that reads notes from an Obsidian vault and prefers the Obsidian CLI before falling back to filesystem search. The exact same command works when I ask Codex to run it manually in an interactive chat:

obsidian help

Observed behavior:

• Interactive Codex chat: obsidian help succeeds and prints normal CLI help.
• Scheduled Codex automation run: Obsidian CLI invocation fails and the automation logs show that the Obsidian command exited with code 134.

This makes the behavior look specific to the scheduled automation execution context, rather than to the Obsidian installation itself.

Obsidian version on this machine:

• 1.12.4 (CFBundleVersion 0.14.8)

What steps can reproduce the bug?

1. Create a recurring Codex desktop automation that runs on a schedule.
2. In the automation prompt, invoke the Obsidian CLI as part of the task. A minimal example would be:

obsidian help

1. Let the automation run automatically on schedule.
2. Compare that behavior with running the same command manually in an interactive Codex conversation.

What reproduces consistently for me:

• Manual interactive Codex conversation: succeeds.
• Scheduled automation execution: fails with exit 134.

Relevant context:

• The automation was running inside Codex Desktop.
• The issue is not that the command is wrong; the same command works when manually run through Codex chat.
• The failure seems tied to the scheduled automation launch context.

What is the expected behavior?

Commands run by a scheduled Codex automation should have the same ability to invoke the Obsidian CLI as commands run manually in an interactive Codex conversation.

Specifically, if:

obsidian help

works in the current Codex session, then the same command should not fail with exit 134 only because it was launched by the scheduler.

Additional information

This does not currently look like a normal vault file permission problem:

• The same user account can run the Obsidian CLI successfully in an interactive Codex chat.
• The failure is specific to scheduled automation execution.
• The exit code is 134, which suggests a process-level abort rather than a normal CLI validation error.

Relevant versions:

• Codex desktop: 26.305.950 (CFBundleVersion 863)
• Obsidian: 1.12.4 (CFBundleVersion 0.14.8)
• macOS: Darwin 25.3.0 arm64 arm

Notes on crash evidence:

• I do have older historical Obsidian .ips crash logs from previous days in ~/Library/Logs/DiagnosticReports/.
• However, I do not currently have a new 2026-03-09 crash log that I can directly attribute to today's failing scheduled automation run.
• So for this report, the strongest direct evidence is the reproducible difference between:
• interactive Codex chat: success
• scheduled Codex automation: exit 134

If useful, I can also provide the automation prompt and the exact automation run timestamps.