[Bug][Codex App] keep-native-v1 stamps Sol as v1 but fresh Sol tasks still run V2

[bluesmilery]

Client or integration

Codex App

Area

Catalog / models

Summary

With multiAgentMode: "v2" and keepNativeChatGptOnV1: true, OpenCodex correctly stamps the native gpt-5.6-sol catalog row as multi_agent_version: "v1", but a fresh Codex App task using that model still starts with multi_agent_version: "v2".

As a result, spawning a routed xai/grok-4.6 child sends an encrypted V2 NEW_TASK and fails with unreadable_encrypted_agent_task.

I expected the fresh native Sol parent to use the V1 collaboration surface, as documented by the keep-native-v1 setting and implemented by PR #1728, while routed parents remain on V2.

This is distinct from the underlying encrypted V2 transport limitation in #92: the setting intended to avoid that native-parent V2 path is enabled and reflected in the catalog, but is not reflected in the runtime turn context.

Reproduction

1. Configure OpenCodex:

   ocx v2 mode v2
   ocx v2 keep-native-v1 on
   ocx agent subagents set xai/grok-4.6,gpt-5.6-sol,gpt-5.6-terra,gpt-5.6-luna,zhipu/glm-5.3
   ocx sync --restart-codex

2. Verify the effective OpenCodex status:

   multi_agent_v2: ON
   multi_agent_mode: v2
   keep_native_chatgpt_on_v1: ON
   

3. Verify both the generated catalog and models_cache.json contain:

   {
     "slug": "gpt-5.6-sol",
     "multi_agent_version": "v1",
     "use_responses_lite": true
   }

4. Fully restart the Codex App, create a new top-level task using native gpt-5.6-sol, and ask it to spawn xai/grok-4.6.

5. Inspect the new parent task's turn_context.

   Actual:

   {
     "model": "gpt-5.6-sol",
     "multi_agent_version": "v2"
   }

6. The child is created with xai/grok-4.6 and V2, then immediately fails before inference:

   unreadable_encrypted_agent_task
   Routed V2 worker task is encrypted for the native ChatGPT backend and cannot be read by the selected provider.
   

Timing ruled out a stale in-memory catalog in this reproduction: the catalog and model cache were refreshed before the Codex App app-server started, and the new task was created after that app-server start.

Potentially relevant: ocx status reports that OpenCodex is configured against Codex CLI 0.147.0, while the Codex App app-server reports 0.148.0-alpha.15, along with the warning that OpenCodex is using an older Codex binary.

Version

OpenCodex 2.27.0; Codex App embedded CLI 0.148.0-alpha.15; OpenCodex configured Codex runtime 0.147.0

Operating system

macOS 26.6.2 (25G83), Apple Silicon arm64

Provider and model

Parent: native OpenAI / gpt-5.6-sol; child: xAI / xai/grok-4.6

Logs or error output

multi_agent_v2: ON — v2 multi-agent surface active
multi_agent_mode: v2 — ALL models forced to v2 surface
keep_native_chatgpt_on_v1: ON — ChatGPT-native rows stay v1 when mode is v2

catalog: gpt-5.6-sol -> multi_agent_version=v1
parent turn_context: gpt-5.6-sol -> multi_agent_version=v2
child turn_context: xai/grok-4.6 -> multi_agent_version=v2

error.code=unreadable_encrypted_agent_task

Screenshots and supporting files

No attachments. The relevant redacted status, catalog metadata, parent turn context, and child error are included above.

Redacted configuration

{
  "multiAgentMode": "v2",
  "keepNativeChatGptOnV1": true,
  "subagentModels": [
    "xai/grok-4.6",
    "gpt-5.6-sol",
    "gpt-5.6-terra",
    "gpt-5.6-luna",
    "zhipu/glm-5.3"
  ]
}

Checks

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

Related

• V2 cross-provider sub-agent loses NEW_TASK body in encrypted_content #92 — upstream encrypted V2 task transport limitation
• [UX] Explain native-to-routed V2 compatibility and recovery state for preferred sub-agents #1533 — compatibility/recovery UX
• feat(agents): keep ChatGPT-native models on v1 when catalog is v2 #1728 — implementation of keepNativeChatGptOnV1

[coderabbitai]

🔗 Related PRs

#1876 - fix(windows): keep catalog discovery off request event loop [merged]
#2113 - feat(providers): allow trusted encrypted V2 task passthrough [open]
#2162 - fix(anthropic): frame the opening turn so AgentRouter stops blocking non-English [merged]
#2134 - fix(subagents): keep a saved roster slot listed when its model is disabled [merged]
#2112 - fix(catalog): allow per-provider/model opt-out of code_mode_only tool mode (#2106) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[lidge-jun]

리뷰 · 우선순위 71 / 80

카탈로그 도장은 진짜로 v1임. src/codex/catalog/parsing.ts applyMultiAgentMode가 mode === "v2" + keepNativeChatGptOnV1이면 catalogEntryIsNativeChatGpt인 줄만 multi_agent_version = "v1"로 찍음. tests/multi-agent-keep-native-v1.test.ts가 gpt-5.6-sol → v1, xai/grok-4.6 → v2를 이미 잠가둠. ocx v2 keep-native-v1 on은 src/cli/v2.ts에서 플래그 저장하고 syncModelsToCodex까지 돌림. 이슈가 본 models_cache.json이 v1인 건 이 경로가 산 거임.

런타임이 그 도장을 안 읽음. 새 Sol 부모 turn_context.multi_agent_version이 v2임. 그래서 자식 xai/grok-4.6이 암호화된 V2 NEW_TASK를 받고 unreadable_encrypted_agent_task로 죽음. #92 우회하려고 만든 스위치가 카탈로그에만 있고 세션 생성에는 없음. ocx v2 status 문구도 헷갈림. 모드는 "ALL models forced to v2"인데 바로 아래 줄은 네이티브가 v1이라고 함. 카탈로그는 후자고, 앱은 전자를 믿는 중임.

CLI/앱 버전 갈라진 것도 단서임. ocx가 Codex CLI 0.147.0을 보고, 앱 서버는 0.148.0-alpha.15임. 카탈로그를 앱이 다시 해석하면 우리 도장이 무시됨. 타이밍(캐시)은 이슈가 이미 잘라냈음. 재시작 이후 새 태스크에서도 v2면 주입 경로 버그거나 앱이 multi_agent_mode: v2를 전역으로 덮는 거임.

#2113 암호화 V2 패스스루랑 합치지 마. 그건 우회고, 이건 네이티브 부모를 V1에 붙이는 공식 스위치가 죽은 거임. #1533 UX도 별개임. 카탈로그만 고친 PR은 이 이슈를 닫으면 안 됨.

해결방안: 세션/턴 생성에서 catalog row의 multi_agent_version을 turn_context로 복사하는 지점을 찾아라. 앱이 전역 v2로 덮으면 그 덮기를 네이티브 부모에서 막아라. 0.147 vs 0.148 불일치도 재현 조건에 넣어라. 카탈로그 테스트는 이미 초록이라 그걸 더 조이는 패치는 가짜 고침임. 스플릿 무관. 2.28 직후 손댈 버그임.

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

[lidge-jun]

restart codex and it apply to new session if it reproduce please repopen the issue