Codex cannot read registerCliHandler results when the handler returns after a short delay
I found what looks like a bug or incompatibility between Codex and Obsidian CLI plugin commands.
I ran into this while building a plugin that extends the Obsidian CLI for automation / agent use.
Versions and environments
-
NixOS/install via home-manager
-
Obsidian Installer
1.12.7 -
Obsidian:
1.12.7 -
Codex:
118.0
Summary
If a community plugin registers a CLI command with plugin.registerCliHandler(...), Codex can read the command output when the handler returns quickly, but Codex cannot read the result when the handler returns after a short delay.
I put a minimal reproduction plugin here:
https://github.com/daichi-629/long-run-command-bug-repro-plugin
Minimal plugin reproduction
import { Plugin, type CliHandler } from "obsidian";
export default class ReproPlugin extends Plugin {
async onload(): Promise<void> {
const handler: CliHandler = async () => {
const start = Date.now();
await new Promise((resolve) => window.setTimeout(resolve, 20));
return JSON.stringify(
{ durationMs: Date.now() - start },
null,
2
);
};
this.registerCliHandler("repro-sleep", "repro", null, handler);
}
}
Expected
obsidian repro-sleep
should return JSON like:
{
"durationMs": 20
}
Comparison
Works:
- Running the same command directly from a shell returns the expected JSON.
- Telling Codex to invoke the command in TTY mode also returns the expected JSON.
- In Codex normal mode, a delay around
15msstill seems to work.
Fails:
- In Codex normal mode, a delay around
20msstarts producing empty stdout. - Exit code is still
0.
So this looks like a timing-dependent failure around the Codex execution path for Obsidian CLI plugin handlers.
What I checked
- I had Codex repeatedly run the command while varying the delay.
- This does not seem to be a general delayed stdout problem.
- The issue seems to show up specifically when a
registerCliHandler(...)command returns only after a slightly longer delay.
My main question is:
- is this likely a Codex-side stdout capture issue?
- or is this likely an Obsidian CLI /
registerCliHandler(...)issue?