[Bug]: Codex App now sends gpt-5.6-luna helper requests on every message and turn completion (previously only title generation)

[fede-oss]

Client or integration

Codex App

Area

Proxy and routing

Summary

Since 2026-08-19 ~22:15 UTC, my usage.jsonl fills with one-shot gpt-5.6-luna requests arriving roughly every time I send a message in any Codex App thread and again every time an agent turn completes (~50/hour during active use). Before that date, for weeks, the only background luna traffic I saw was the single title-generation call per newly created thread — which I understand and expect.

I'm opening this to ask: why this sudden change, and is there an OpenCodex-side way to identify/label or intercept these calls?

What I've been able to determine so far:

• The calls are Codex App-originated: admissionKind: loopback, inboundProtocol: responses, requestedEffort: low, ~16–18k input tokens (base instructions + message excerpt), tiny outputs (20–90 tokens), status 200, native route to OpenAI.
• Each call has a unique conversationId that matches no session rollout file; the app appears to run them in ephemeral threadSource: system threads (fresh session id per call).
• Timing correlates 1:1 with thread events: one call within ~2–4s of each user message sent, one near each turn completion, across all concurrent threads (verified against rollout user_message/task_complete timestamps for 7 threads; 32 messages + 28 turn ends ≈ 50 luna calls/hour).
• Inspecting the Codex App binary (26.814.41407, runtime 0.148.0-alpha.15): these match the thread_summary feature ("one-line activity update displayed beneath an existing Codex task title", phases user and assistant), hardcoded to gpt-5.6-luna with effort low, plus related thread_title/thread_description/ambient_suggestion* helpers. Generation and rendering appear gated by an app-side remote feature flag.
• Upstream reports of the same class of hidden background calls: Codex Analytics attributes turns to gpt-5.6-luna with no local Luna invocation evidence openai/codex#37751 (analytics attributes luna turns the user never started), Memory writer sends hardcoded gpt-5.6-luna and gpt-5.6-terra requests to non-OpenAI model providers openai/codex#37009 (hardcoded luna/terra memory-writer model ids), [Windows Desktop] Background ambient/home suggestions consume user quota without explicit action openai/codex#29380 (ambient suggestions consuming quota, no off switch).
• My shadowCallIntercept is currently disabled; I see it historically targeted exactly this helper family (see In Codex 0.147.0, background helper requests use gpt-5.6-luna. Even with OpenCodex's Shadow Call Intercept enabled, some Luna requests still reached OpenAI. #1684, Shadow call intercept no longer matches Codex 0.145.0 shadow model (gpt-5.6-luna) #311, Background help model sometimes invalid #1402, [Bug]: Background helper model dropdown shows "[object Object]" for models with icons #668).

Questions:

1. Is this per-message/per-turn luna helper traffic a known recent Codex App behaviour change (0.148.0-alpha.x), and is it expected to persist?
2. Would enabling shadowCallIntercept catch these specific calls (they don't look like the older shadow calls; they arrive as normal loopback /v1/responses requests in ephemeral system threads), or do they need separate handling?
3. Could OpenCodex label/aggregate these background-helper rows separately in usage.jsonl / the dashboard (or offer a filter), so they're distinguishable from real agent traffic?

Reproduction

1. Run OpenCodex with Codex App pointed at the proxy (openai_base_url injection).
2. Open several threads and chat normally (each user message + each completed turn is a trigger).
3. Watch usage.jsonl: expect one gpt-5.6-luna row (effort low, ~16–18k in, 20–90 out, unique conversationId) within a few seconds of every message send and every turn completion, in addition to the per-new-thread title-generation call.

Version

2.26.0 (auto-updated from 2.21.0 at 2026-08-19T22:07Z)

Operating system

macOS 15.7.9

Provider and model

openai (native passthrough) / gpt-5.6-luna

Logs or error output

# representative row from usage.jsonl (redacted; conversationId is the app-side hashed session id)
{"requestId":"ocx-mt0nwt4l-11","timestamp":1787178459765,"provider":"openai","model":"gpt-5.6-luna","admissionKind":"loopback","inboundProtocol":"responses","accountLogLabel":"main","conversationId":"141eca32880ea487342aef6b3c3f3152","requestedModel":"gpt-5.6-luna","requestedEffort":"low","status":200,"durationMs":2273,"usage":{"inputTokens":17950,"outputTokens":20},"routeDecision":{"routeKind":"native","selected":{"provider":"openai","model":"gpt-5.6-luna","reason":"native-family"}}}

Redacted configuration

{
  "shadowCallIntercept": { "enabled": false, "model": "gpt-5.6-luna" },
  "webSearchSidecar": { "model": "gpt-5.6-luna", "backend": "openai", "streamRoutedModelOutput": true },
  "subagentModels": ["gpt-5.6-sol", "gpt-5.6-terra", "gpt-5.6-luna"]
}

Checks

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

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• In Codex 0.147.0, background helper requests use gpt-5.6-luna. Even with OpenCodex's Shadow Call Intercept enabled, some Luna requests still reached OpenAI. #1684

🔗 Related PRs

#1876 - fix(windows): keep catalog discovery off request event loop [merged]
#2134 - fix(subagents): keep a saved roster slot listed when its model is disabled [open]
#2148 - fix(providers): allow a baseUrl override for Anthropic and Antigravity [open]
#2113 - feat(providers): allow trusted encrypted V2 task passthrough [open]
#2080 - feat(openrouter): B2 — Fast on OpenAI-backed slugs, no route pinning (#1886) [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!

[Ingwannu]

I checked this against current dev at caf20353f.

This traffic is not created by OpenCodex. With shadowCallIntercept.enabled: false, a normal loopback gpt-5.6-luna request is intentionally passed through, so the timing is consistent with an app-side helper/remote-flag change rather than the OpenCodex 2.26.0 update creating extra calls.

For question 2: enabling the intercept does catch this current shape. shouldInterceptShadowCall() now matches every bare configured shadow source model regardless of x-codex-turn-metadata.request_kind, and the regression suite explicitly covers a Luna request labeled request_kind: "turn" after #1684/#1685. A configured target can be enabled with:

ocx models shadow set <provider/model> --enabled on

There is one real OpenCodex observability gap in this report: the request path sets shadowCallRewrittenFrom when it rewrites a helper call, but RequestLogContext and the field-by-field usage.jsonl persistence projection do not retain that marker. As a result, intercepted helper rows cannot currently be labeled or filtered durably even though the runtime recognized them.

I will fix that bounded logging contract: add a typed, non-sensitive persisted helper marker and regression coverage. I will not infer thread_summary versus title/description from timing, and I will not auto-intercept Luna while the option is disabled, because ordinary user-selected Luna requests are indistinguishable at that boundary.

[lidge-jun]

리뷰 · 우선순위 42 / 80

ocx 회귀가 아님. Codex App thread_summary가 gpt-5.6-luna effort low로 유저 메시지/턴 끝에 원샷을 쏨. 예전엔 스레드 만들 때 title 하나. 0.148.0-alpha 쪽 리모트 플래그로 보임. openai/codex#37751 #37009 #29380이랑 같은 가족임.

ocx는 admissionKind: loopback /v1/responses로 받아서 네이티브 OpenAI로 보냄. conversationId가 세션 롤아웃이랑 안 맞음. threadSource: system 일회성. usage.jsonl이 에이전트 트래픽이랑 섞임. shadowCallIntercept는 꺼져 있고 예전 섀도 패밀리(#1684 #311 #1402 #668)라 이 루프백 헬퍼를 자동으로 안 잡을 가능성 큼.

막는 스위치는 앱 쪽임. ocx가 할 일은 라벨/필터. 2.27이랑 무관. 코드 버그 티켓으로 닫지 말 것.

점수는 42임. 쿼타를 먹긴 함. 우선은 대시보드에서 luna 헬퍼를 접는 쪽.

해결방안: usage 행에 helper/thread_summary 태그. 모델+effort+ephemeral system thread+16k 입력/짧은 출력으로 휴리스틱. shadowCallIntercept가 이 셰이프를 먹는지부터 확인. 앱 플래그 끄는 법은 업스트림 이슈로.

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

[Ingwannu]

The focused observability fix is now in PR #2163.

It persists the typed, bounded, and redacted shadowCallRewrittenFrom marker into usage.jsonl and restores it during request-log hydration after restart. This keeps opt-in intercepted helper traffic distinguishable from ordinary agent traffic without inferring thread_summary, title, or description calls from timing or token counts.

The current request-path regression also confirms that a bare configured Luna source is intercepted when shadowCallIntercept is enabled even when the request carries request_kind: "turn". Interception remains opt-in; this PR does not enable it automatically and does not alter the GUI.

Verification completed:

• focused request-log and shadow-intercept tests: 65 pass / 0 fail
• typecheck and privacy scan: passed
• full suite: 13,532 pass / 15 skip / 1 host-environment-only token-fixture failure
• the contaminated shim file rerun with OPENCODEX_API_AUTH_TOKEN removed: 69 pass / 0 fail

I have requested review from @lidge-jun and will not self-approve or self-merge.

[lidge-jun]

Shipped in v2.28.0, now on npm as latest (release).

The Logs surface now names these requests instead of leaving them as anonymous traffic: an intercepted helper call carries an I · <model> badge, and an "Intercepted helpers only" filter isolates them, so you can see exactly how many the app sent and when. That landed in #2179 along with the attribution work in #2166 and #2170 that made the marker durable and safe to record.

To be precise about what this does and does not do: it makes the behaviour visible and countable, which is what this issue asked for first. It does not change how often the Codex App decides to send a helper request — that decision is the app's, not the proxy's. If the volume is still a problem for you after upgrading, the Logs filter now gives you the exact numbers to open that as its own report.

Closing as shipped. Reopen if the badge or filter does not show what you are seeing.