[Provider compatibility] OpenCode Go wire contract: missing x-opencode-session and unsanitized indexed_web_access

[lidge-jun]

Provider

OpenCode Go (opencode-go)

What is the compatibility problem?

Two independently reported defects on the same provider, both caused by OpenCodex not modelling what the OpenCode Go endpoint requires on the wire. Each is closed individually and absorbed here:

• OpenCode Go requests are missing x-opencode-session #3344 (@colthreepv) — requests are missing x-opencode-session
• [Bug]: OpenCode Go Muse Spark 1.3 rejects Codex web_search indexed_web_access #3362 (@0disoft) — Muse Spark 1.3 rejects Codex web_search indexed_web_access

Missing session header. The opencode-go registry row in src/providers/registry.ts defines no session-header behavior, and x-opencode-session appears nowhere under src/. Requests therefore arrive without the session identity the upstream expects.

Unsanitized web_search field. The Muse sanitizer in src/adapters/openai-responses.ts removes search_content_types but preserves indexed_web_access, which Muse Spark 1.3 rejects. The sanitizer knows this tool needs field-level filtering; it just does not filter this field.

Both are the same shape of bug: a provider-specific wire requirement that the adapter does not represent, so the request is well-formed for OpenAI and wrong for this upstream.

Expected behavior

1. opencode-go requests carry a stable x-opencode-session value for the life of a session.
2. The Muse sanitizer drops indexed_web_access alongside search_content_types, and the sanitizer's field list is expressed so that the next rejected field is a one-line addition rather than a new investigation.

Reproduction

Send any Codex request through an opencode-go provider and inspect the outbound headers for x-opencode-session. For the second defect, send a Codex web_search turn to Muse Spark 1.3 and observe the upstream rejection naming indexed_web_access.

Additional context

Absorbs #3344 and #3362. Credit for the original reports belongs to @colthreepv and @0disoft, who each supplied the upstream evidence that made these diagnosable.

Checks

• I searched existing issues and documentation.
• I removed secrets and personal data.

[lidge-jun]

리뷰 · 우선순위 74 / 80

이 이슈는 OpenCode Go 제공자가 업스트림이 요구하는 와이어를 두 곳에서 빠뜨린 버그를 한곳에 모은 것입니다. 기능 요청이 아니라, 지금 dev에서 재현되는 호환성 구멍입니다. 첫 번째: x-opencode-session 헤더가 src/ 안에 없습니다. src/providers/registry.ts의 opencode-go 행은 adapter: "openai-chat", 베이스 URL https://opencode.ai/zen/go/v1이고 세션 헤더 동작이 없습니다. 그래서 Codex 요청이 OpenAI 모양으로는 맞지만, Go 엔드포인트가 기대하는 세션 식별이 빠집니다. 두 번째: Muse Spark 1.3이 Codex web_search의 indexed_web_access를 거절합니다. src/adapters/openai-responses.ts의 stripMuseSparkUnsupportedWebSearchFields는 muse-spark-1.3-contributor / 1.2-contributor에서 search_content_types만 떼고, indexed_web_access는 그대로 둡니다. 주석도 “거절하는 필드만 지운다”고 적혀 있는데, 거절 목록이 한 필드뿐입니다.

두 버그의 모양은 같습니다. OpenAI에는 정상인 요청이 이 업스트림에는 틀립니다. 흡수된 #3344와 #3362는 닫혀 있고, 원 제보자 @colthreepv / @0disoft 가 업스트림 증거를 준 상태라 조사부터 다시 할 이슈가 아닙니다. indexed_web_access는 src/에 심볼로도 안 나옵니다. 새 필드가 아니라, 이미 나가는 바디를 안 지우는 것입니다. 세션 헤더는 레지스트리 행에 넣을지, openai-chat 어댑터의 제공자별 헤더 훅에 넣을지 정해야 합니다. 값의 수명은 “세션 동안 안정”이어야 하고, 매 요청마다 새 UUID를 만들면 업스트림이 세션을 못 붙입니다.

우선순위가 높은 이유는 수정 단위가 작고, 지금 트래픽이 400으로 죽을 수 있기 때문입니다. Muse 쪽은 거부 필드 목록을 배열로 바꿔 search_content_types 옆에 indexed_web_access를 한 줄 더하는 편이, 다음 거절 필드가 나올 때 조사를 반복하지 않습니다. 본문이 요청한 바로 그 모양입니다. 세션 헤더는 테스트에서 outbound 헤더를 잠그면 됩니다. types/config 분할과는 무관합니다.

src/providers/registry.ts opencode-go 행 - 세션 헤더 동작이 없고, src/ 전체에서 x-opencode-session 문자열이 없습니다.

src/adapters/openai-responses.ts stripMuseSparkUnsupportedWebSearchFields - search_content_types만 제거하고 indexed_web_access는 통과시킵니다. Muse Spark 1.3이 그 필드를 거절합니다.

흡수된 #3344 / #3362 - 닫혀 있고 이 이슈가 남은 범위입니다.

메인테이너의 판단이 필요한 지점

• x-opencode-session 값을 대화 id로 할지, OpenCodex가 만든 안정 세션 id로 할지.
• Muse 거절 필드를 배열로 일반화할지, 이번엔 indexed_web_access만 추가할지.
• 두 버그를 한 PR에 넣을지(같은 제공자 와이어) 헤더/새니타이저로 나눌지.

너의 추천
이 이슈를 열어 두고 빨리 고치세요. 한 PR로 (1) opencode-go outbound에 세션 동안 안정적인 x-opencode-session을 붙이고, (2) Muse 새니타이저 거절 목록에 indexed_web_access를 넣으세요. 테스트로 헤더와 필드 제거를 잠그면 됩니다. 흡수된 원본은 다시 열지 마세요.

이 댓글은 grok-bot이 작성했습니다

[lidge-jun]

Fixed by #3405, squash-merged into dev as 20011a1.

Both absorbed defects are covered. opencode-go requests now carry a stable opaque x-opencode-session derived from the existing session lane, held across Chat, Responses, and API-key rotation, with an operator-provided header still taking precedence. The Muse sanitizer drops indexed_web_access alongside search_content_types for plain web_search on the affected Spark models, leaving preview tools and other models untouched, and the field list is now shaped so the next rejected field is a one-line addition.

The two absorbed reports #3344 (@colthreepv) and #3362 (@0disoft) were already closed, so nothing further is owed there.

Closing manually: these pull requests target dev, and GitHub only auto-closes linked issues on the default branch.

Thanks @adtumk.

[DaveW001]

Confirming this from the released line, not dev. I'm on @bitkyc08/opencodex@2.41.0 (Windows, Codex Desktop routed through the local proxy) and received the same "Missing OpenCode Go Header" email from updates@opencode.ai on September 3: same Bun fetch user agent, same warning that requests without the header may error starting 09/06.

The absence is easy to verify in the shipped package. The opencode-go row in src/providers/registry.ts points at https://opencode.ai/zen/go/v1 with no session-header behavior, and the openai-chat transport only sets Content-Type and Authorization for that host.

One scheduling concern. v2.42.0 was tagged before #3405 merged (compare v2.42.0...20011a1c reports behind by 0, ahead by 6), so no npm artifact, including latest and preview, carries the fix yet. With enforcement starting 09/06, everything on a published version stays exposed through the weekend. Is a cut containing 20011a1 realistic before then? I can run with a manually configured session header in the meantime, but the derived per-conversation behavior in #3405 is what I actually want.