Timeout test Cli opencode local

[Fredb34670]

I'm using Open Design Desktop and I'm having a timeout problem on the OpenCode test.

• OS : Windows 11
• Open Design version : 0.6.0
• OpenCode version : 1.14.48 installé via npm
• opencode --version répond instantanément
• opencode serve démarre correctement
  But the test in the parameters times out consistently after 45 seconds. The daemon log shows: [test:agent] OpenCode → timeout in 45.0s.
  With Gemini CLI installed, there are no problems.
  The OpenCode desktop and CLI versions are installed.

[open-design-bot]

🎉 ✨ Welcome to Open Design, @Fredb34670!

✨ 🔥 Lit the spark.

🌱 Every contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

[lefarcen]

Hi @Fredb34670! Thanks for the clear report — the OS/version details and the daemon line are exactly the useful bits here. 👀

Working hypothesis: the 45.0s value is Open Design's Local CLI connection-test budget, not OpenCode's serve path. For this Settings test, the daemon spawns OpenCode as a CLI smoke run and waits for an ok reply; opencode --version and opencode serve can both be healthy while that smoke run still takes longer than 45s.

One important detail: Open Design 0.6.0 was released before the connection-test timeout became configurable, and 0.7.0 is now available. Could you try updating to 0.7.0 and rerun the OpenCode test once?

If it still times out, the smallest next clues would be:

where.exe opencode
opencode --version

plus the few daemon log lines immediately before/after [test:agent] OpenCode → timeout in 45.0s, and the selected OpenCode model in Settings. That should tell us whether this is just a slow first response, a model/auth issue inside OpenCode, or a Windows PATH/env difference between the desktop daemon and your terminal.

We’ll keep this tracked as a bug while we narrow it down. 🙏

[Fredb34670]

After various tests and installing version 0.7.0, it appears that when launching a request with a local LLM in OpenCode Desktop, the test in OpenDesign on OpenCode times out. However, if I launch OpenCode (including the CLI version) in the OpenCode Desktop terminal and attach the local LLM, the test in OpenDesign works. OpenCode Desktop uses the OpenCode CLI engine, if I'm not mistaken?

Was that clear? :>)

[lefarcen]

Hey @Fredb34670 — yes, that is clear, and it is a helpful distinction. 🙌

My read is: OpenCode Desktop may use the same OpenCode CLI engine, but Open Design does not attach to the already-running OpenCode Desktop session. For the Settings test, Open Design's daemon starts a fresh CLI smoke run (opencode run ...) from its own process environment and waits for a tiny reply.

So your result points toward an initialization/env/config boundary: opening OpenCode Desktop's terminal and attaching the local LLM seems to prepare something that the later Open Design-spawned CLI can then see. Without that step, the fresh CLI process starts but does not produce the smoke-test reply before the timeout.

One small confirmation would help: after a reboot, if you start only Open Design and run the OpenCode test, does it fail again until you open OpenCode Desktop's terminal and attach the local LLM once? If yes, that gives us a very concrete repro shape to investigate on the daemon/OpenCode config side.

[Fredb34670]

After launching Open Design, the OpenCode test times out. An LLM needs to be connected to the OpenCode CLI for it to work. It might be helpful to mention this during the test. Also, simply installing OpenCode Desktop isn't enough, at least not for the test.

On another note, though unrelated: Would it be possible for you to translate the following sections into French in the settings: External MCP, Routines, MCP Server, Privacy? Sincerely,