Bug: async work (fetch / cmd.exec) inside mod event handlers is dropped or never resolves in the interactive TUI

Bug: async work (fetch / cmd.exec) inside mod event handlers is dropped or never resolves in the interactive TUI

Summary

When a mod runs fetch (or cmd.exec) inside an event handler like run_end or onRunEnd, the promise never resolves in the interactive TUI — even though the same call resolves in ~1s standalone. The mod's async work is silently dropped, so post-turn hooks that do network I/O never complete.

Repro

Minimal mod:

export default function (cmd: any) {
	cmd.on('run_end', (event) => {
		void fetch('https://api.commandcode.ai/provider/v1/chat/completions', {
			method: 'POST',
			headers: {'Content-Type': 'application/json', Authorization: 'Bearer ' + require('node:fs').readFileSync(require('node:os').homedir() + '/.commandcode/auth.json', 'utf8') /* parse */},
			body: JSON.stringify({model: 'moonshotai/Kimi-K2.7-Code-Highspeed', messages: [{role: 'system', content: 'Reply OK'}], max_tokens: 10}),
			signal: AbortSignal.timeout(60_000),
		})
		.then(r => console.error('RESOLVED', r.status))
		.catch(e => console.error('FAILED', e.message));
	});
}

Expected: RESOLVED 200 within ~2s of the run ending.
Actual: neither RESOLVED nor FAILED ever logs — the promise never settles. Same with cmd.exec({command: 'curl', ...}) inside onRunEnd: the exec starts (a telltale writes) but never returns.

Evidence (from the suggester mod's debug log)

20:31:39.354  run_end fired, scheduling regenerate
20:31:39.385  fetch: attempt 0 start
20:32:00.078  fetch: attempt 0 status=200   ← resolves 21s later, or never in some runs

Timing is inconsistent: sometimes it resolves after ~20s, sometimes never. In the interactive TUI it's far more likely to never resolve than in headless -p.

What I had to do to work around it

Spawn a standalone helper process (a separate node script) from the mod: the mod writes a request file (sync), spawns the helper with child_process.spawn, and the helper does the fetch in a normal process where it works reliably. This is ugly but necessary — in-module async network I/O is not dependable.

Notes

• onRunEnd is documented as "awaited before the run_end event" — the hook itself runs, but its async body doesn't complete.
• cmd.exec inside onRunEnd/run_end shows the same behavior (starts, never returns).
• This is why the docs' "must-complete work" claim for onRunEnd doesn't hold for I/O.

Environment

• Command Code 1.15.0, macOS 26 (arm64)
• Mods loaded from ~/.commandcode/mods/ (user scope)

Impact

Any mod that does network I/O or subprocess work in a post-turn hook is unreliable. The workaround (helper process) is a significant complexity tax on mod authors.

Bắt đầu với việc dispatch TUI tương tác cho các event handler run_end và onRunEnd, sau đó tái hiện vấn đề bằng mod được cung cấp với fetch và cmd.exec. So sánh hành vi của TUI tương tác với việc thực thi headless bằng -p; được xem là hoàn tất khi các promise sau lượt chạy luôn được resolve hoặc reject một cách đáng tin cậy và các subprocess trở về mà không cần một tiến trình trợ giúp.