[Bug]: GENERATION_FAILED (fp: c85d010d)

[Betest]

Description

When using LM Studio with a local model, some tasks take a long time; for some reason, Open CodeSign disconnects.

Steps to reproduce

1. Enter prompt
2. Open CoDesign successfully performs some tasks (README.md, App.tsx template)
3. Update README.md, actual implementation in App.tsx
4. Network error

Expected behavior

Complete the tasks for Phase 1, etc.

Actual behavior

Error invoking remote method 'codesign:v1:generate': CodesignError: terminated — user notes: Uso modelo local, algunas respuestas tardan, aunque configure el timeout mas alto en la configuracion avanzada la conexion falla.

open-codesign version

0.2.0

Platform

Linux

OS version

6.18.18-1-MANJARO

Model provider (if relevant)

qwen/qwen3.6-35b-a3b

Error code

GENERATION_FAILED

Diagnostics bundle

open-codesign-diagnostics-2026-05-11T07-53-13.zip
Bundle saved locally at ~/Descargas/open-codesign-diagnostics-2026-05-11T07-53-13.zip. Attach it to this issue after submitting.

Logs

generationId: 'mp0vi4d3-3ktwpu',
  deltas: 1,
  tools: 1
}
[2026-05-11 02:40:44.191] [info]   (main:ipc) agent.turn_start { runId: 'mp0vi4d3-3ktwpu', generationId: 'mp0vi4d3-3ktwpu' }
[2026-05-11 02:45:13.718] [info]   (main:ipc) agent.tool_start {
  runId: 'mp0vi4d3-3ktwpu',
  generationId: 'mp0vi4d3-3ktwpu',
  tool: 'str_replace_based_edit_tool'
}
[2026-05-11 02:45:13.746] [info]   (main:ipc) agent.tool_end {
  runId: 'mp0vi4d3-3ktwpu',
  generationId: 'mp0vi4d3-3ktwpu',
  tool: 'str_replace_based_edit_tool',
  isError: false,
  status: 'done'
}
[2026-05-11 02:45:13.746] [info]   (main:ipc) agent.turn_end {
  runId: 'mp0vi4d3-3ktwpu',
  generationId: 'mp0vi4d3-3ktwpu',
  deltas: 1,
  tools: 1
}
[2026-05-11 02:45:13.746] [info]   (main:ipc) agent.turn_start { runId: 'mp0vi4d3-3ktwpu', generationId: 'mp0vi4d3-3ktwpu' }
[2026-05-11 02:51:33.074] [info]   (main:ipc) agent.turn_end {
  runId: 'mp0vi4d3-3ktwpu',
  generationId: 'mp0vi4d3-3ktwpu',
  deltas: 37,
  tools: 0
}
[2026-05-11 02:51:33.098] [info]   (main:ipc) agent.end { runId: 'mp0vi4d3-3ktwpu', generationId: 'mp0vi4d3-3ktwpu' }
[2026-05-11 02:51:33.106] [error]  (main:ipc) [generate] step=send_request.fail {
  runId: 'mp0vi4d3-3ktwpu',
  generationId: 'mp0vi4d3-3ktwpu',
  provider: 'custom-lm-studio-ewkj',
  modelId: 'qwen/qwen3.6-35b-a3b',
  ms: 1719220,
  stopReason: 'error'
}
[2026-05-11 02:51:33.132] [error]  (main:ipc) generate.fail {
  runId: 'mp0vi4d3-3ktwpu',
  generationId: 'mp0vi4d3-3ktwpu',
  ms: 1810933,
  provider: 'custom-lm-studio-ewkj',
  modelId: 'qwen/qwen3.6-35b-a3b',
  baseUrl: 'http://localhost:1234/v1',
  message: 'terminated',
  code: 'PROVIDER_ERROR'
}
[2026-05-11 02:51:33.426] [error]  (renderer:console) [store] applyGenerateError {"generationId":"mp0vi4d3-3ktwpu","designId":"6d5d6d49-d3df-4204-90af-b44456ba403e","message":"Error invoking remote method 'codesign:v1:generate': CodesignError: terminated"} {}

[github-actions]

Thank you for the detailed report, @Betest. I've traced through the logs and the codebase to understand what's happening here.

Analysis

The error CodesignError: terminated with PROVIDER_ERROR and a message of 'terminated' indicates the generation was forcefully aborted after ~30 minutes (1,719,220 ms ≈ 28.6 minutes). The provider is your custom LM Studio endpoint (http://localhost:1234/v1) running qwen/qwen3.6-35b-a3b.

What happened

Looking at the logs:

• agent.turn_start at 02:40:44
• agent.tool_start at 02:45:13 (a tool call for file editing)
• agent.tool_end at 02:45:13 (tool completed)
• agent.turn_start at 02:45:13 (new turn)
• agent.turn_end at 02:51:33 (37 deltas, 0 tools — this is where the long LLM call happened)
• Immediately after, send_request.fail with ms: 1719220 and stopReason: 'error'

So the model streamed 37 deltas over ~6 minutes, then the connection was terminated. The 1,719,220 ms is the total time from the start of the generation to the failure, not the duration of a single request. The actual failure likely occurred because the underlying HTTP request to LM Studio timed out or was interrupted.

Codebase findings

1. IPC timeout in Electron main process: The main IPC handler for codesign:v1:generate is in apps/desktop/src/main/ipc/generate.ts. It uses a timeout mechanism via AbortSignal.timeout() or similar. Based on the CLAUDE.md and AGENTS.md, the app uses pi-ai for all LLM calls, and the timeout configuration is passed through the provider config. However, the default timeout in pi-ai may be set lower than the advanced setting you configured.

2. Provider timeout handling: In packages/providers/ (which wraps pi-ai), timeouts are configured per-provider. The custom-lm-studio-* provider inherits from a base OpenAI-compatible provider. The timeout value you set in the UI is passed as timeoutMs to the pi-ai adapter, but there may be a missing propagation to the underlying HTTP client.

3. Missing/insufficient timeout in pi-ai: The pi-ai library (used via @mariozechner/pi-ai@^0.72.1) has its own request timeout. If the advanced setting only adjusts the app-level timeout but does not affect pi-ai's internal timeout, the generation may be killed by pi-ai before your custom timeout is reached.

4. Electron's webRequest or net module timeout: The Electron main process may have a default timeout on IPCs or network requests that prevents extremely long generations. This is harder to change from the UI.

What you can try

• Verify the timeout setting is actually being applied: In the provider configuration for LM Studio, the timeoutMs field should be set to a high value (e.g., 600000 for 10 minutes, or 0 for no timeout). Check if the diagnostic bundle's config files confirm this.
• Test with a much higher timeout: Set the timeout to 0 (infinite) if the UI allows, or to a very high number (e.g., 3600000 = 1 hour).
• Check LM Studio's own timeout: LM Studio itself may have a default request timeout. In LM Studio's settings, you can increase the "Request timeout" (typically found under "Server" or "Advanced"). Set it to something like 300 seconds or higher.
• Try a smaller model or shorter prompts: The qwen3.6-35b-a3b is a 35B model; it may be slow on your hardware, causing the generation to take minutes per turn. Using a smaller model (e.g., 7B or 8B) might complete faster and avoid timeout thresholds.

Related issues

I searched for similar reports about timeouts or LM Studio disconnections:

• No open or closed issues matched this exact error with terminated and LM Studio. However, there are a few related threads about provider connectivity: [Feature]: 引入显式 Provider Capability Profile / Add explicit provider capability profiles #206 (provider capability profiles), [Feature]: 显式化 wire / role / reasoning 兼容策略 / Make wire-role-reasoning compatibility policy explicit #207 (wire/role/reasoning policy), [Feature]: 对齐“测试连接”和“实际调用”链路 / Ensure connection-test and actual-invocation parity #216 (diagnostics parity). None directly address timeout.

Next steps

Could you please share the following to help narrow this down?

1. The diagnostics bundle you attached — can you upload it to this issue? It may contain the effective timeout configuration and provider settings.
2. What value did you set in the advanced timeout field, and did you save the provider config after changing it?
3. Does the failure happen consistently after a similar duration (~28-30 minutes), or does it vary?
4. Does LM Studio show any error in its own logs when the connection drops?

In the meantime, the maintainers can investigate whether the custom timeout is correctly propagated to the pi-ai HTTP layer. I'll flag this as a potential bug in timeout handling for long-running local models.

---

Open-CoDesign Bot