OpenCode backend fails right after server is ready (message payload/schema mismatch)

[myagizmaktav]

Summary

When Pilot is configured with the OpenCode backend, GitHub issue pickup works up to branch creation and OpenCode server startup, but execution fails immediately on the first send to OpenCode.

Environment

• Pilot: 2.100.1
• OpenCode: 1.4.6
• OS: Linux amd64
• Backend: opencode
• Working OpenCode CLI model: openai/gpt-5.4-mini

Reproduction

1. Configure Pilot with executor.type: opencode.
2. Configure OpenCode server, for example:
   • server_url: http://127.0.0.1:44096
   • server_command: opencode serve --hostname 127.0.0.1 --port 44096
   • model: openai/gpt-5.4-mini
   • provider: openai
3. Enable GitHub polling for a labeled issue.
4. Start Pilot with pilot start --replace.
5. Let Pilot pick up a GitHub issue.

Expected

Pilot should create a branch, send the task prompt to OpenCode, and start backend execution.

Actual

Pilot reaches all setup stages, including OpenCode server startup, then fails immediately on the first backend send.

Observed sequence:

• issue picked up
• branch selected/created
• Starting OpenCode server
• OpenCode server ready
• immediate failure on send

Representative log lines:

OpenCode server ready
Backend execution failed ... error="failed to send message: message failed ..."

In an earlier run, the nested validation payload included:

Invalid input: expected object, received string

for the model field path.

Additional Notes

• opencode run --model openai/gpt-5.4-mini hello works on the same machine, so the provider/model itself is usable from OpenCode CLI.
• The failure seems specific to Pilot -> OpenCode server integration, not OpenCode server startup.
• We also confirmed Pilot reaches OpenCode server ready, so this does not look like a connection-refused/startup issue.

Why this looks like a Pilot/OpenCode integration issue

Direct OpenCode CLI usage works, but Pilot fails when sending the task payload to the OpenCode server endpoint. That suggests request shape/protocol drift between Pilot and OpenCode server APIs.

If useful, I can provide a fuller redacted log excerpt, but the key failure is reproducible at the first send step after server readiness.

[myagizmaktav]

Adding a more detailed and anonymized report after further testing.

Anonymized Setup

• Private GitHub repository used only as a reproduction target
• Single labeled issue in that repository
• Linux amd64 environment
• Pilot upgraded from 2.99.1 to 2.100.1
• OpenCode version: 1.4.6
• Backend configured as opencode

No private repository name, local username, or local project path is relevant to the failure. The same behavior reproduces in a generic private repo once GitHub polling is working.

Important Clarification

This does not look model-specific. We reproduced the same failure with multiple working OpenCode models.

Tested directly with OpenCode CLI and confirmed working:

• opencode run --model openai/gpt-5.4-mini hello
• opencode run --model dokproxy/gpt-5.4 hello

Both succeed when called directly via OpenCode CLI.

What Pilot Successfully Does Before Failure

With GitHub polling enabled and a labeled issue available, Pilot successfully:

1. Finds the GitHub issue
2. Queues the task
3. Starts worker execution
4. Creates or switches to branch pilot/GH-1
5. Starts OpenCode server
6. Reaches OpenCode server ready

So these parts are not failing:

• GitHub issue discovery
• task queueing
• branch setup
• OpenCode process startup
• local HTTP reachability of OpenCode server

Actual Failure Point

Failure happens immediately on the first message send from Pilot to the OpenCode server API.

Representative flow:

Processing issue in sequential mode
Task queued
Switched to existing branch pilot/GH-1
Starting OpenCode server
OpenCode server ready
Backend execution failed

The nested validation error is the most important signal:

Invalid input: expected object, received string

and it points at:

path=["model"]

The failing payload excerpt in logs looks like this shape:

{
  "data": {
    "model": "dokproxy/gpt-5.4",
    "parts": [
      { "text": "[PILOT-EXEC] ..." }
    ]
  }
}

The same schema-level failure also happened earlier with:

"model": "openai/gpt-5.4-mini"

So changing models does not fix it.

Why This Looks Like a Protocol / Schema Mismatch

Direct model execution through OpenCode CLI works.
OpenCode server startup from Pilot also works.
Failure occurs only when Pilot sends the actual execution payload to the OpenCode server.

That strongly suggests one of these:

• Pilot is still sending an older OpenCode request shape
• OpenCode server now expects model as a structured object rather than a string
• there is version drift between Pilot's OpenCode backend implementation and current OpenCode server API

Also Tested

• Upgrading Pilot to 2.100.1 did not resolve the issue
• Switching from openai/gpt-5.4-mini to dokproxy/gpt-5.4 did not resolve the issue
• OpenCode direct CLI invocation still works in both cases

Non-Root-Cause Noise Observed During Testing

These showed up during repeated test runs but do not appear to be the root cause:

• Telegram polling conflict from multiple bot instances
• gateway port 9090 already in use during overlapping runs

Those are side issues from repeated local testing. Even when isolating the OpenCode path, the backend still fails at the same request validation point.

Practical Conclusion

From an integration perspective, the current failure is:

Pilot can reach and start OpenCode, but cannot send a task payload that the OpenCode server accepts.

If helpful, I can add a fully redacted longer log excerpt, but at this point the key reproducer is stable and model-independent.

[myagizmaktav]

I opened a fix PR for this issue:

• PR: fix(executor): support modern opencode message schema #2408

What changed:

• Pilot now sends the modern OpenCode /session/{id}/message payload with:
  • typed text parts ({"type":"text","text":"..."})
  • object-form model ({"providerID":"...","modelID":"..."})
• It falls back to the legacy string-model payload only when the server validation error indicates an older schema.

Validation performed:

• focused executor tests for model normalization, payload building, and compatibility retry
• go test ./internal/executor/... passed
• direct local OpenCode API check confirmed:
  • modern payload accepted
  • legacy payload rejected with path=["model"] / expected object, received string
• local smoke test with a real GitHub issue progressed past the previous immediate failure after OpenCode server ready

Note:

• go test ./... on this clone still shows existing baseline failures in desktop git-graph tests unrelated to this fix. I confirmed the same failures on a clean baseline worktree before opening the PR.

[myagizmaktav]

Additional update: PR #2408 now also includes the false-negative OpenCode dependency detection fix.

This addresses the separate symptom where Pilot could actually start and use OpenCode, but pilot doctor / startup output still reported:

• ✗ opencode not found [active backend]

After rebuilding locally, verification now shows:

• ✓ opencode 1.4.6 [active backend]

So PR #2408 now covers both:

1. OpenCode message schema compatibility
2. active-backend OpenCode dependency detection

[alekspetrov]

Fixed in v2.100.3 via PR #2414 (modern OpenCode message schema: typed text parts + object-form model). External PR #2408 was closed unmerged; the fix was re-done internally and shipped. Please retry on v2.100.3+.