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.

从 run_end 和 onRunEnd 事件处理程序的交互式 TUI dispatch 开始，然后使用提供的 mod 配合 fetch 和 cmd.exec 重现该问题。将交互式 TUI 的行为与 headless -p 执行进行比较；完成的标准是 turn 后的 promise 能可靠地 resolve 或 reject，并且子进程无需辅助进程即可返回。