opencode run hangs intermittently after "init count=" before session creation (headless, 1.18.29, WSL2)

Summary

opencode run (headless, non-interactive) intermittently hangs right after plugin/skill initialization, before any session is created: the log ends at message=init count=81 and no created id= line ever appears. The process stays alive until killed by an external timeout. Roughly 2 out of 5 runs on this machine; re-running the same command usually works.

Environment

• opencode 1.18.29 (linux-x64 binary), @opencode-ai/plugin 1.18.25
• Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 (WSL2, Ubuntu), Node v24.16.0
• Config: ~/.config/opencode/opencode.json with two local plugins (./plugins/*.ts) and oh-my-openagent@4.19.4; ~80 skills, several with duplicate names across ~/.claude/skills, ~/.agents/skills and ~/.config/opencode/skills (see WARN lines below)
• Command shape: opencode run --dir ~ "<prompt>" (also reproduced with --log-level debug and with a trivial prompt)

What happens

stderr / opencode.log for a hung run (56 lines, identical shape every time; only the tail shown):

timestamp=2026-09-06T18:36:03.406Z level=WARN run=82278793 message="duplicate skill name" name=claude-handoff existing=~/.claude/skills/claude-handoff/SKILL.md duplicate=~/.agents/skills/claude-handoff/SKILL.md
... (7 more "duplicate skill name" WARN lines)
timestamp=2026-09-06T18:36:03.411Z level=INFO run=82278793 message=init count=81

Then nothing: no created id=, no tool calls, no model request visible; sisyphus-recon plugin (records every hook payload) shows only plugin.init and one tui.toast.show, no chat.*/tool.*/shell.env hooks. The process never exits on its own (killed at 150 s / 1800 s by our wrappers).

Frequency and history

• Scanning the whole opencode.log since 2026-06-10: 17 runs end at init count= without a subsequent created id= (an earlier scan with a looser pattern counted 25).
• Occurs both before and after our newest plugin was added (23 of the 25 predate it), and with a plugin that only returns a shell.env hook and does nothing at load time, so it does not look plugin-specific.
• Successful runs, same command a few seconds later, proceed normally to created id= and complete.

Expected

Either the session is created or the run fails fast with an error; a silent hang before session creation is hard to detect from cron wrappers (we currently rely on an external timeout).

Notes

• The duplicate skill name warnings are the last thing logged before the hang in every case; not claiming causality, but worth checking whether skill discovery / plugin init has a race or an unawaited promise when the same skill name resolves from multiple roots.
• Happy to run a debug build or add extra logging if you point me at the right flag.