[Bug] reasoning `encrypted_content` was not issued to this caller

[nitg3n]

Client or integration

Codex App

Area

Proxy and routing

Summary

I tried to use opencode-go/muse-spark-1.3-contributor, and it made an error Error from provider (Console Go): Upstream request failed: [invalid_request_error] reasoning `encrypted_content` was not issued to this caller.
There is a similar issue on omp repo(can1357/oh-my-pi#11928)

Reproduction

1. ocx start
2. use opencode-go/muse-spark-1.3-contributor
3. error occurs

Version

2.52.0

Operating system

Windows 11 25H2

Provider and model

opencode-go/muse-spark-1.3-contributor

Logs or error output

invalid_request_error
Error from provider (Console Go): Upstream request failed: [invalid_request_error] reasoning `encrypted_content` was not issued to this caller

Screenshots and supporting files

There is no limit problem. It was okay when I used other models from OpenCode Go.

Redacted configuration

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[lidge-jun]

리뷰 · 우선순위 66 / 80

설명
이 이슈는 Codex App에서 opencode-go/muse-spark-1.3-contributor를 고르면 업스트림이 invalid_request_error / reasoning encrypted_content was not issued to this caller 로 거절한다는 보고다. 같은 계열 오류가 omp(oh-my-pi) 쪽에도 있다. 보고 버전은 2.52.0, OS는 Windows 11이고, OpenCode Go의 다른 모델은 된다고 한다. 스크린샷상 quota/limit 문제는 아니다.

지금 dev HEAD d0cbfffdd(package 2.53.0) 기준으로 보면, OpenCode Go 레지스트리는 muse-spark-1.3-contributor(와 1.2 contributor)를 modelWireDefaults로 openai-responses에 올려 둔다. 같은 엔트리에 statelessResponses: true가 있고 주석이 말한다. “Go rejects reasoning.encrypted_content with previous_response_id (#3838).” 즉 Go는 previous_response_id와 암호화 reasoning 재전송 조합에 예민하고, 그래서 상태 파라미터를 깎는 정책을 이미 켠 상태다. stripStatefulResponsesParams는 previous_response_id·conversation·background·metadata·prompt를 지우고 store:false를 강제한다. 하지만 그 경로만으로는 input 안의 reasoning.encrypted_content 블롭 자체를 항상 지우지는 않는다.

실제 블롭 제거는 src/adapters/openai-responses.ts의 sanitizeReasoningInputContent가 한다. 지금은 (1) 프록시가 만든 ocxr1: 봉투이거나 (2) opts.stripEncryptedContent === true일 때만 encrypted_content를 삭제한다. 그리고 stripEncryptedContent 옵션은 요청에 _stripReasoningEncryptedContent가 켜질 때 들어간다. 그 플래그는 src/server/responses/core.ts에서 reasoning replay serving identity가 바뀌었을 때, opaque-blob 거절이 메모되었을 때, prepareOpaqueBlobRecovery 같은 복구 경로에서만 sticky로 켠다. 같은 Go 자격·같은 라우트로 이어지는 Codex App 멀티턴에서는 identity-change 조건이 안 걸려, Muse가 이전에 준(또는 다른 caller가 준) encrypted_content가 그대로 재전송될 수 있다. Go/Muse가 “이 caller에게 발급된 적 없는 블롭”으로 보면 보고와 같은 400이 난다. 다른 Go 모델은 Chat 와이어이거나 reasoning 암호화 재전송을 안 해서 증상이 안 보이는 설명과도 맞는다.

#3838은 이미 닫힌 Go 입력 정규화(추가 툴·agent_message) 계열이고, 이 이슈의 정확한 문구와는 겹치되 해결책이 “항상 encrypted_content 제거”까지는 아니다. #4454는 mixed encrypted agent_message 히스토리의 fail-closed 구멍으로 인접하지만, 증상 문자열이 reasoning 블롭 caller 검증 실패라서 SSOT를 이 이슈에 두는 편이 맞다. tip 2.53.0에 이 문구를 직접 고친 커밋은 보이지 않으므로, 보고자 2.52.0만의 회귀로 단정하지 말고 tip에서도 재현 여부를 먼저 확인하는 게 좋다.

우선순위 66은 Codex App 사용자가 Go Muse Contributor를 고르면 턴이 바로 죽는 체감이 크고, 수정 후보는 sanitize/registry 한두 가드 + fixture로 좁힐 수 있으며, #4468/#4470 문서 단위와 파일 겹침이 거의 없기 때문이다. 다만 재현이 첫 턴인지(클라이언트/include 설정) 둘째 턴 이후인지(리플레이)에 따라 고치는 지점이 달라서, 로그 한 장이 필요하다.

src/providers/registry.ts opencode-go (statelessResponses, modelWireDefaults["muse-spark-1.3-contributor"]) - Muse Contributor는 Responses로 간다. 주석의 #3838은 previous_response_id + encrypted_content 민감도를 이미 인정한다. 지금 정책은 상태 파라미터 제거까지이고, reasoning 블롭 상시 제거는 아니다.

src/adapters/openai-responses.ts sanitizeReasoningInputContent - 네이티브 encrypted_content는 identity-change/opaque-recovery일 때만 stripped. Go Muse가 caller 발급 검증을 하면, 같은 라우트 리플레이도 400이 될 수 있다. 후보 수정: Go 목적지(또는 muse-spark* on Go)에서 항상 strip, 혹은 statelessResponses 목적지에서 네이티브 블롭 strip.

src/adapters/openai-responses.ts stripStatefulResponsesParams - previous_response_id 등은 제거하지만 reasoning item 필드는 안 건드린다. #3838 주석만으로 이 이슈가 이미 막혔다고 보면 안 된다.

src/server/responses/core.ts _stripReasoningEncryptedContent 설정 지점 - identity change / opaque blob memo / prepareOpaqueBlobRecovery. “같은 Go 키로 이어진 Codex App 멀티턴”은 여기 안 걸릴 수 있다.

심볼 오류 문구 reasoning encrypted_content was not issued to this caller / 관련 #3838(닫힘), #4454(agent_message, 별 SSOT) - 이 이슈를 Muse/Go reasoning 블롭 재전송 버그의 본표로 두는 게 맞다.

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

• tip 2.53.0에서 Codex App → opencode-go/muse-spark-1.3-contributor 재현을 먼저 받을지(첫 턴 vs 툴콜 이후 턴).
• 고정을 Go 전체 상시 strip으로 갈지, muse-spark*만으로 좁힐지, opaque-blob 거절 문구를 메모해 다음 요청에 strip하는 반응형으로 갈지.
• Meta 직행(meta-model/meta-muse)·Zen 경로와 동작을 맞출지, Go gateway 제약만 특별 취급할지.

너의 추천
bug/proxy 유지하고 needs-repro로 한 턴만 더 받으세요. 재현 확인 후 첫 PR은 Go(또는 Go+muse-spark) outbound에서 reasoning.encrypted_content를 상시 제거하는 쪽을 기본 후보로 두고, fixture로 “블롭 있는 리플레이가 Go URL에서 strip되는지”를 잠그세요. #3838/#4454를 다시 열지 말고 이 이슈를 SSOT로 두세요. types/config 분할과 무관합니다.

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

[nitg3n]

I found a pattern:

• Fresh Muse conversations work, including multi-turn.
• An older conversation that was already using Muse before the update fails with "reasoning encrypted_content was not issued to this caller".
• Another older conversation that originally used GPT-5.6 Luna works after switching to Muse.

So this seems related to specific pre-existing Muse conversation state/history, not simply old vs new chats or a specific version.

[Ingwannu]

Thanks — the fresh Muse multi-turn success and the old Luna-to-Muse success materially narrow this. They do not support treating all old conversations, all Muse continuations, or all Go reasoning replay as broken.

At current dev 6aaab49f6, the existing statelessResponses setting removes stateful request parameters, but it is not a blanket removal of native reasoning.encrypted_content. The adapter strips that field when the replay/recovery flag is set. There is also a narrower point to investigate in src/server/responses/core.ts::isSelfIdentifiedOpaqueBlobRejection: it recognizes specific rejection codes/messages, not arbitrary encrypted-content errors. The reported "was not issued to this caller" wording alone does not match its current code-less message checks; whether your response already carries a recognized code matters.

Could you provide the HTTP status and the sanitized error object's type, code and message from one failure, plus exact OCX/client versions? Please replace any blob embedded in the message with [REDACTED]. If available, include only request-log attempt/recovery counts and whether the provider credential or selected account changed since that conversation last worked — never the credential itself. No raw conversation, encrypted payload or account identifiers are needed.

That will distinguish an unrecognized authoritative rejection from a recovery that ran and still failed. I would keep healthy same-caller replay intact while checking this narrower recovery boundary, rather than implement blanket stripping on the evidence so far. This remains open; no fix or upstream-account reproduction is claimed.

[nitg3n]

For the failing request:

• HTTP status: 400
• error type: unavailable (not exposed)
• error code: invalid_request_error
• message:
  reasoning encrypted_content was not issued to this caller

Request log:

• attempts: 1
• sendCount: 1
• recoveryKinds: []

ocx/client:

• opencodex: 2.52.0
• previous conversation was created/used before the update (possibly 2.48.0)
• Codex App: 26.908.40834

Additional context:

• Fresh Muse Spark 1.3 Contributor conversations on the current version work.
• Existing GPT-5.6 Luna conversations switched to Muse also work.
• Some existing Muse Spark conversations fail after continuing them.
• I also found at least one older Muse Spark conversation that still works, so this does not appear to affect all old Muse conversations.

[lidge-jun]

Fixed on dev by 44027ae.

src/server/responses/core.ts now treats the reported "was not issued to this caller" body as an opaque-blob rejection rather than a generic failure, so the reasoning encrypted_content reaches the caller that asked for it. A focused recovery test in tests/responses/responses-opaque-blob-recovery.test.ts pins the path.

Hosted CI was green at the exact merged head.