bug(desktop): macOS generation fails with Instructions are required and no visible output

[Sun-sunshine06]

Summary

On macOS, generation can fail with a custom provider / GPT-5.4 setup and the app produces no visible output. The user only sees a generic generation failure, while diagnostics show the underlying error:

Error invoking remote method 'codesign:v1:generate': CodesignError: 400 Instructions are required

This appears to be surfaced as a RENDERER_ERROR, but the logs suggest the request made it through build_request.ok and failed after send_request, so the classification and user-facing error handling may be misleading.

User Impact

• macOS users can repeatedly hit generate and get no output at all
• the UI does not provide an actionable explanation
• the failure is easy to misread as a renderer issue, while the actual problem looks like an upstream/provider request contract error

Environment

• App: 0.1.3
• Platform: darwin
• Electron: 39.8.8
• Node: 22.22.1
• Provider: custom-custom-bt65
• Model: gpt-5.4

Diagnostic Report

• Code: RENDERER_ERROR
• Fingerprint: 0414cb45
• Occurred at: 2026-04-22T06:08:36.761Z
• Bundle path: /Users/wuhao/Downloads/open-codesign-diagnostics-2026-04-22T06-10-16.zip

Error Seen In Diagnostics

[store] applyGenerateError {"generationId":"mo9njby6-g8208z","designId":"c572117b-5068-4e74-86b1-7d4640272721","message":"Error invoking remote method 'codesign:v1:generate': CodesignError: 400 Instructions are required"}

Relevant Log Tail

[generate] step=build_request.ok {
  runId: 'mo9nl6uz-y9t0ja',
  generationId: 'mo9nl6uz-y9t0ja',
  provider: 'custom-custom-bt65',
  modelId: 'gpt-5.4',
  ms: 1,
  messages: 3,
  skills: 0,
  skillWarnings: 0
}
[generate] step=send_request {
  runId: 'mo9nl6uz-y9t0ja',
  generationId: 'mo9nl6uz-y9t0ja',
  provider: 'custom-custom-bt65',
  modelId: 'gpt-5.4'
}
agent.turn_start { runId: 'mo9nl6uz-y9t0ja', generationId: 'mo9nl6uz-y9t0ja' }
[context-prune] step=caps {
  runId: 'mo9nl6uz-y9t0ja',
  generationId: 'mo9nl6uz-y9t0ja',
  messages: 2,
  before: 253,
  after: 253,
  textLimit: 8192,
  toolInputLimit: 24576,
  toolResultLimit: 8192,
  window: 3
}

Notes / Hypotheses

Possible causes to investigate:

• request shape mismatch for custom providers targeting gpt-5.4
• missing or empty instructions field in a Responses-style request path
• provider adapter not translating prompt/messages correctly for this custom endpoint
• error classification is too generic (RENDERER_ERROR) and hides the real failure mode from users

Expected Behavior

One of the following should happen:

• generation succeeds on macOS with this provider/model setup, or
• the app shows a clear provider/request validation error explaining what is missing, instead of a generic failure / no-output experience

Suggested Follow-up

• inspect the custom provider request builder for gpt-5.4
• log the effective request mode/path (chat vs responses) for this provider
• surface provider-side 400 contract errors more directly in the UI
• consider classifying this separately from renderer errors

[github-actions]

Thanks for the detailed report and diagnostics — this is very helpful.

I verified the current flow in code, and your log sequence is consistent with the implementation:

• build_request.ok is emitted before provider send, then send_request happens, and provider failures are raised from that send path.
• For non-Codex providers, generation goes through runGenerate(...) (not the ChatGPT/Codex path).

Based on the code, two things are currently true:

1. Your upstream 400 Instructions are required can propagate as the user-visible message, but diagnostics can still be classified as RENDERER_ERROR when renderer logs don’t include an explicit error code.
2. Only the dedicated Codex route explicitly sets an instructions field; the generic provider path builds system/user messages and passes them through pi-ai context mapping.

Relevant code:

• packages/core/src/index.ts:621 — emits [generate] step=build_request.ok
• packages/core/src/index.ts:311 — emits [generate] step=send_request
• apps/desktop/src/main/index.ts:638 — normal provider generation path (runGenerate)
• packages/providers/src/index.ts:163 — wire model maps openai-responses to api: 'openai-responses'
• packages/providers/src/index.ts:286 — system messages are collapsed into systemPrompt
• apps/desktop/src/main/codex-generate.ts:154 — Codex path builds explicit instructions
• apps/desktop/src/main/codex-generate.ts:241 — Codex request sends instructions
• apps/desktop/src/renderer/src/store.ts:866 — generate failure logged via console.error
• apps/desktop/src/renderer/src/lib/renderer-logger.ts:98 — patched console.error forwarded without explicit data.code
• apps/desktop/src/main/diagnostics-ipc.ts:334 — missing data.code falls back to RENDERER_ERROR

Need more info:

• In Settings for custom-custom-bt65, is wire set to openai-responses or openai-chat?

Since Open CoDesign is still pre-alpha, some provider-edge behavior is still being hardened, and this report is exactly the kind of signal that helps us tighten request validation and error classification.

---

open-codesign Bot

[Sun-sunshine06]

Possibly related UI-state issue: see #136.

A user screenshot shows the top bar model as opus-4-7, while Settings for the current Claude Code (imported) provider shows claude-3-5-haiku-20241022 on the active card.

If the actual generate request is resolved from a different provider/model source than the one users see in the top bar, that could help explain why upstream validation errors are so confusing to reproduce and diagnose.