Repository navigation
[Bug]: Codex App now sends gpt-5.6-luna helper requests on every message and turn completion (previously only title generation) #2157
Description
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: systemthreads (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_completetimestamps 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_summaryfeature ("one-line activity update displayed beneath an existing Codex task title", phasesuserandassistant), hardcoded togpt-5.6-lunawith effortlow, plus relatedthread_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
shadowCallInterceptis 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:
- 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?
- Would enabling
shadowCallInterceptcatch these specific calls (they don't look like the older shadow calls; they arrive as normal loopback/v1/responsesrequests in ephemeral system threads), or do they need separate handling? - 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
- Run OpenCodex with Codex App pointed at the proxy (
openai_base_urlinjection). - Open several threads and chat normally (each user message + each completed turn is a trigger).
- Watch
usage.jsonl: expect onegpt-5.6-lunarow (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.
Activity
coderabbitai commentedon Aug 19, 2026
🔗 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 plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
Ingwannu commentedon Aug 20, 2026
I checked this against current
devatcaf20353f.This traffic is not created by OpenCodex. With
shadowCallIntercept.enabled: false, a normal loopbackgpt-5.6-lunarequest 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 ofx-codex-turn-metadata.request_kind, and the regression suite explicitly covers a Luna request labeledrequest_kind: "turn"after #1684/#1685. A configured target can be enabled with:There is one real OpenCodex observability gap in this report: the request path sets
shadowCallRewrittenFromwhen it rewrites a helper call, butRequestLogContextand the field-by-fieldusage.jsonlpersistence 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_summaryversus 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 commentedon Aug 20, 2026
리뷰 · 우선순위 42 / 80
ocx 회귀가 아님. Codex App
thread_summary가gpt-5.6-lunaeffort 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 commentedon Aug 20, 2026
The focused observability fix is now in PR #2163.
It persists the typed, bounded, and redacted
shadowCallRewrittenFrommarker intousage.jsonland restores it during request-log hydration after restart. This keeps opt-in intercepted helper traffic distinguishable from ordinary agent traffic without inferringthread_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
shadowCallInterceptis enabled even when the request carriesrequest_kind: "turn". Interception remains opt-in; this PR does not enable it automatically and does not alter the GUI.Verification completed:
OPENCODEX_API_AUTH_TOKENremoved: 69 pass / 0 failI have requested review from @lidge-jun and will not self-approve or self-merge.
feat(gui): show and filter intercepted helper requests in Logs
docs(devlog): attach the #2157 Logs screenshots for the PR gate
lidge-jun commentedon Aug 20, 2026
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.
feat(gui): show and filter intercepted helper requests in Logs
docs(devlog): attach the lidge-jun#2157 Logs screenshots for the PR gate