Opening the ChatGPT desktop app silently consumes the Codex weekly limit (fixed 6% per background suggestion run; reproduced under controlled conditions)

Summary

Simply having the ChatGPT desktop app (bundled Codex Framework) open — without submitting any prompt — consumes the Codex weekly rate limit. In a controlled experiment I measured a fixed 6% deduction of the weekly window triggered by app-initiated background activity (pending turns / ambient suggestions on previously opened sessions). Quitting the app stops the drain immediately.

This has repeatedly consumed my weekly limit while I was not using Codex at all (2026-07-21, 07-29→07-30 full burn 100%→0% in ~11h, 08-01, and now reproduced on 08-07).

Controlled experiment (2026-08-05 ~ 08-07, KST)

I isolated variables one at a time, polling GET /backend-api/wham/usage (rate_limit.primary_window.used_percent) every 15–30 min:

Phase	Condition	Result
1	All clients dead (logged out, app quit, reboot)	103h 47m, 0% consumed
2	Valid credentials (`auth.json` refreshed), app quit	~41h, 0% consumed
3	ChatGPT.app launched 14:33; user opened past sessions ~20:15	20:20–21:36: 97% → 91%, exactly −6% (≈1%/15min display progression)
4	App quit 21:41	Drain stops immediately; 91% held for hours

Cross-checks during the −6% window:

No local Codex CLI sessions (~/.codex/sessions empty for that day).
No cloud tasks (GET /backend-api/wham/tasks → empty list) — and the drain stopped on app quit, so it was not server-side task execution.
The app produced 3 notifications for old threads (e.g. codex://threads/019fb91a-2935-7a73-94d0-8c23b5bbe41a), i.e. the app executed pending turns/auto-suggestions on threads I merely had open — I never submitted anything.

Prior observation of the same fixed cost

On 2026-07-22 (clean window after reset) I measured ambient/personalized suggestions twice: 9 projects (52 model calls) → −6%; 1 project (4 model calls) → −6%. 13× the work, identical 6% charge. The 08-07 reproduction makes it sample n=3. The weekly limit appears to be quantized (~16–17 slots) and one background suggestion run costs one slot regardless of size.

Why this is a problem

No user intent: opening the app (even just to check remaining quota) can cost 6% of the weekly window. On 07-29→07-30 this contributed to a 100%→0% burn in ~11 hours with zero user prompts, locking me out for what was scheduled as 6+ days.
No disclosure: nothing in the UI indicates that ambient suggestions / auto-resumed turns consume the weekly limit, nor their fixed 6% cost.
Delayed display: the deduction surfaces gradually (~1%/15min), so users cannot see the cost in real time.
Support (case 11918266) repeatedly answered with unrelated web-error checklists and workspace-admin docs; the server-side usage ledger I requested was never provided.

Expected behavior

Background/ambient activity should be opt-in, or at minimum clearly labeled with its quota cost.
Usage accounting should be proportional to actual work, not a fixed 6% per run.
A user-accessible usage ledger (what consumed the limit, when) — the local logs cannot show app-direct backend calls.

Environment

macOS (Darwin 25.5.0), ChatGPT.app with Codex Framework 151.0.7922.71 (com.openai.codex)
Plan: ChatGPT Plus (individual)
Related in-app feedback ID: 019f81f9-9e2b-78f3-b78e-42b4df0c3f64

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Desktop-bundled Codex: guardian_subagent approvals reviewer enabled without consent; background memory jobs drain plan quota while idle #36733
Unexplained Usage #36848
[ChatGPT Desktop] Weekly usage jumped from 16% to 75% after reset with no local requests during a 5-hour gap #36481

Powered by Codex Action

Live reproduction #3, minutes after filing this issue.

After quitting the app (drain stopped, 91% held for >1h), I relaunched the app at ~22:5x KST and left it idle — no prompts submitted.

23:10 KST: used_percent 9 → 10 (remaining 91% → 90%), app idle in background.

That is now three consecutive on/off cycles with the same result: launch → drain begins, quit → drain stops immediately, relaunch → drain resumes. I am continuing 15-minute polling with the app left open to see whether this run also settles at exactly −6% (i.e. 85%), consistent with the fixed-cost quantization described above. Will post the completed curve here.

Re the potential duplicates flagged by the bot (#36733, #36848, #36481): these describe the same symptom family — the desktop app consuming weekly quota while idle — but this issue is not a plain duplicate. What it adds:

A controlled experiment with a negative control: 103h 47m with all clients dead → 0% consumed; ~41h with valid credentials but app quit → 0% consumed. The drain occurs only while the app is running, verified over three consecutive launch/quit cycles (launch → drain begins, quit → stops immediately, relaunch → resumes).
A fixed-cost measurement: exactly −6% per background run regardless of workload (n=3 including two 2026-07-22 measurements where 52 model calls and 4 model calls each cost the identical 6%), suggesting the weekly window is quantized (~16–17 slots).
Confirmation that the traffic is app-direct to the backend (no local CLI sessions, no cloud tasks, nothing through a local proxy ledger), which is why affected users find no local evidence — consistent with what [ChatGPT Desktop] Weekly usage jumped from 16% to 75% after reset with no local requests during a 5-hour gap #36481 and Unexplained Usage #36848 report as "no local requests".

Happy to have a maintainer consolidate these under one tracking issue; until then I'll keep this open as the controlled-reproduction dataset. I can provide the full minute-resolution TSV log on request.

The controlled launch/quit experiments make one missing product primitive very visible: every billable background execution needs a durable causal ledger entry that can be joined to the usage deduction.

Right now the user can observe:

usage window changed by 6%
app was open
notifications appeared

but there is no authoritative record saying which logical background operation consumed that quota.

I would give every app-initiated model/background run a stable operation identity and attribution envelope:

operation_id
kind = ambient_suggestion | pending_turn | title | user_turn | ...
trigger = app_launch | thread_open | explicit_user_action | scheduler
thread_id/project_id if applicable
started_at / completed_at
request_count / token usage if available
usage_ledger_entry_id
user_initiated = true|false

Then the usage surface can reconcile server-side deductions against operations instead of showing only an aggregate rolling percentage. For background work, the app can also enforce policy before dispatch: user_initiated=false + billable => require opt-in / declared budget / visible notification, depending on product intent.

The fixed 6% observation is especially important to preserve in diagnostics without assuming the billing mechanism: if quota is slot/quantum-based rather than token-linear, the ledger should record the server's actual charged unit alongside measured model work rather than attempting to infer cost from token counts.

A regression/control test could mirror the reporter's experiment:

app closed 24h             => no background operation ids, no attributed deductions
app launched idle          => any deduction must reference ≥1 background operation
quit app                   => no new background operation starts
same operation retried     => ledger shows retry lineage, not an unexplained second charge

The invariant is: if product-owned background activity can consume a user limit, the causal execution record must be observable and attributable to that limit change.

Root cause identified: Chronicle (desktop screen-memory summaries).

After the drain reproduced, I found ~/.codex/memories/extensions/chronicle/resources/ full of *-10min-memory-summary.md files. Their counts line up with every incident on this account:

Date	Chronicle 10-min summaries generated	Incident
2026-07-21	93	original burn (71% → 0%)
2026-07-22	14	−6% steps after reset
2026-07-29	130	100% → 0% in ~11h
2026-08-01	5	"3% in 36 minutes"
2026-08-07	10	this issue's controlled reproduction (97% → 89%)

On 08-07 the correlation is minute-for-minute: summary files written at 21:15 / 21:26 / 21:37 KST match the ~1%-per-15-min drain readings, and after relaunch, files at 23:06 / 23:17 match the 91→90→89 readings exactly. At roughly 1 summary ≈ 1% of the weekly window, 130 summaries on 07-29 fully accounts for the total burn.

So the mechanism is: with chronicle = true (Settings > Personalization), the desktop app periodically generates screen-context memory summaries via billed model calls while the app is open — no user prompts involved. This matches #36733's "background memory jobs drain plan quota while idle" report.

One open question: the memories.min_rate_limit_remaining_percent startup guard has existed since April (#19990, codex-rs/memories/write/src/guard.rs), yet 07-29 burned to 0%. Either the Chronicle summary path doesn't go through that guard, or generation simply tracks user screen activity (on 08-07, file timestamps coincide with the moments I was actually interacting with the app). Maintainers can tell from the app-side code.

Mitigation that worked here: chronicle = false (and memories = false) in config.toml / Settings > Personalization. Full minute-resolution TSV available on request.

Corroborating this on ChatGPT Pro (the report above is Plus), same OS build (Darwin 25.5.0). Independent measurement, adding to the "background activity burns the weekly window with no user prompt" pattern.

Matching your findings

On 2026-08-05 my weekly window went 0% → 100% while my local rollout logs for that day account for only 17.3M tokens. Consumption is not proportional to local work, which lines up with your quantized-slot model.
My ~/.codex/ambient-suggestions/ contains runs generated at 08:21 and 11:04 on 2026-08-10 that I never requested.
I confirm your point that local logs cannot show this. I spent a full day parsing ~/.codex/sessions/**/*.jsonl and the numbers never reconciled — the implied token cost per 1% swung between 0.1M and 22M depending on the day. Your slot model explains that; token accounting cannot.
Support gave me the same treatment (case opened 2026-08-10): two automated replies about data export, conversation deletion, and account deletion, none of which relate to a billing question.

Additional data from the Chronicle side (not yet in this thread)

Chronicle appears to be a second, separate drain on the same window:

Interval. Docs state 10-minute summaries. I measured 1,436 summaries between 2026-08-03 and 08-10 — an average of roughly one every 7 minutes.
Retention. Docs state recordings are deleted after 6 hours. A full week of summaries remained on disk, plus 1,050 summaries from May 2026 that had been synced to iCloud through ~/.codex/memories_extensions. 1,680 screen-capture JPEGs (434 MB) were also present.
Disabling does not stop the running process. After setting features.chronicle = false, the already-running codex_chronicle process (uptime 6h13m) kept going and rewrote summary files I had just deleted. I had to kill it manually. Only after killing it and restarting the app did it stay down — so the flag appears to be read at launch and ignored at runtime. A user who disables Chronicle to stop the drain keeps paying until they happen to check pgrep.
A memory-consolidation batch processed 159 sessions in one run, taking 2 percentage points of the weekly window at once.

Environment
ChatGPT.app 26.803.41515 / codex-cli 0.147.0 / macOS 26.5.2 (arm64) / Plan: Pro

Supporting your requested fixes

A user-accessible usage ledger is the core issue. Without it, neither of us could attribute our own consumption, and both of us had to run multi-day investigations to recover something the product already knows.

@rikyunezumi61-takanoha

@rikyunezumi61-takanoha Thank you — I can corroborate parts of your Chronicle findings from the original (Plus) account:

Old-location leftovers confirmed here too. ~/.codex/memories_extensions/chronicle/ on this Mac still holds 705 ten-minute summaries from April–May 2026 (6.9 MB), months past any documented retention. So Chronicle had been running on this machine since at least late April.
This also explains why the drain went unnoticed for months. This account was on Pro until 2026-07-15 and switched to Plus then — the same background cost that is invisible inside a Pro-sized window becomes several percent per run on Plus. The incident timeline on this account starts exactly after the plan change.
One behavioral difference from your report: on ChatGPT.app with Codex Framework 151.0.7922.71, after setting chronicle = false (+memories = false) in config.toml without restarting the app, I measured 8 hours with zero window consumption and zero new summary files, and no codex_chronicle process is present now. So the runtime-flag-ignored behavior you observed may be build-dependent — worth including your app build when maintainers triage. Either way your advice stands: after disabling, verify with pgrep -fl chronicle and check ~/.codex/memories/extensions/chronicle/resources/ for fresh files.

Agreed that the root ask remains a user-accessible usage ledger — three independent multi-day investigations (yours, mine, and the earlier duplicates) all exist only because the product doesn't expose what it already knows.

@Tygb99

@Tygb99 Thank you — both for the corroboration and especially for the build-dependent correction. That kind of counter-observation is exactly what keeps a thread like this credible.

Following your advice, I have reported my exact build (ChatGPT.app 26.803.41515, build 6321 / codex-cli 0.147.0) to OpenAI support with the runtime-flag observation scoped to my environment only, noting your 151.0.7922.71 result as evidence it may not be universal.

One additional data point on the "local logs cannot show this" front: my local log store (~/.codex/logs_2.sqlite, 147,055 rows covering 2026-08-02 onward) contains zero rows whose target, module_path, or file fields reference chronicle. So even while the process was demonstrably running and rewriting files, it emitted no log lines locally. Whatever ledger exists is server-side only — which is your root ask, and I agree it remains the core issue.

Your plan-change observation (invisible inside a Pro-sized window, several percent per run on Plus) also matches my timeline from the other side: I was on Pro the whole time and only caught it by reconciling rate-limit records manually.

I observed a related case on a ChatGPT Pro account in the EU, with one important cross-device detail.

Timeline

My weekly Codex meter showed 5% remaining at approximately 19:21.
I submitted no further prompts and had no Codex tasks, CLI sessions, IDE integrations, or scheduled automations running.
ChatGPT Desktop remained open in the background.
The Mac then entered sleep automatically and remained asleep overnight.
At approximately 07:41 the following morning, I checked the usage meter from the ChatGPT iOS app before waking or interacting with the Mac.
The weekly meter was already at 0% remaining.
While it showed 0%, the iOS app would not allow me to add attachments.
The weekly allowance reset at approximately 08:01, at its previously scheduled reset time.

The fact that the server-side meter was already at 0% on iOS before the Mac was awakened rules out the desktop app's wake/resume event as the trigger.

It does not distinguish between:

background activity initiated before the Mac entered sleep,
activity during a macOS background wake,
server-side pending or ambient work associated with the open desktop app,
delayed reconciliation of usage generated earlier.

However, there was no explicit user-initiated Codex activity between the 5% and 0% observations.

Earlier that evening I had separately observed the meter move from 10% remaining to 6% remaining while generating images in an ordinary ChatGPT browser conversation, with no concurrent local Codex requests. Current OpenAI documentation says built-in image generation can count toward general Codex usage limits, so I am treating that measured four-point decrease as a separate event, not necessarily the same bug.

The unexplained event is specifically the final 5% disappearing server-side while the Mac remained asleep, with the result independently visible from iOS before the desktop machine was awakened.

This may still be compatible with the pending-turn or ambient-suggestion behavior described in this issue, but it was not triggered by waking or reopening the desktop client. A user-accessible usage ledger would be needed to identify the actual request or accounting event.

Additional macOS Plus reproduction: hidden ambient_suggestions consume quota

I can independently reproduce this on macOS with a ChatGPT Plus subscription.

I initially had no visible Codex task running and no visible scheduled task, but my remaining Codex allowance dropped from 41% → 39% → 37% within a few hours while Codex Desktop was open.

I then inspected the local Codex operational database at:

~/.codex/logs_2.sqlite

The logs confirm hidden model turns that are not shown as normal foreground tasks.

At 2026-08-20 15:35:49 +08:00, Codex created a synthetic TurnInput beginning with:

Generate 0 to 3 hyperpersonalized suggestions for what this user can do with Codex in this local project...

At 15:35:54, this produced a real sampling request using:

model=gpt-5.6-terra
reasoning_effort=medium

A second background ambient-suggestions turn occurred at 16:07:46, followed by another real gpt-5.6-terra / medium sampling request at 16:07:51.

The logs also contain multiple additional hidden helper turns using gpt-5.6-luna / low to generate one-line activity updates beneath Codex tasks.

Separately, I found one self-deleting heartbeat automation that ran at 15:22:11 using gpt-5.6-terra / xhigh. Because that automation deleted itself after execution, it was no longer visible in the task list afterward. However, the later ambient-suggestions calls occurred independently and demonstrate that quota-consuming hidden background model requests continued outside the visible task list.

After I fully quit Codex Desktop, both ~/.codex/logs_2.sqlite and its WAL stopped being written at approximately 17:56:18.

This appears to be the same class of issue described here: simply keeping the Desktop app open can trigger non-user-initiated model generations that consume a paid Plus allowance.

Please:

Confirm whether ambient_suggestions and activity-summary generations are intentionally charged against the user's Codex allowance.
Provide a supported and clearly documented global opt-out for all background model generations.
Do not charge user quota for model calls that were not explicitly initiated or opted into by the user.
Provide a user-visible usage ledger showing which task/background feature consumed quota and when.
Review whether quota lost to these unsolicited background generations can be restored.

I can provide sanitized SQLite excerpts, timestamps, thread IDs, and screenshots if useful.

In /.codex/config.toml, setting ambient-suggestions-enabled = false might help. It seems usage has been stable since making this change so far (will report again if doesn't work as expected)

Guys OpenAI isn't going to look at this themselves, we need to spam Tibo's feed

lets do it

Guys OpenAI isn't going to look at this themselves, we need to spam Tibo's feed

https://x.com/yong_____jjang/status/2091685199067365741

Additional default-state and configuration evidence

Environment: macOS, ChatGPT desktop 26.818.41509 build 6962, codex-cli 0.149.0.

I do not recall ever seeing or opting into a suggested prompt. However, inspection of this installed app build shows that ambient-suggestions-enabled defaults to true.

The key was absent from ~/.codex/.codex-global-state.json, meaning there was no recorded user opt-in or opt-out and the app used its enabled default.

I also found four older files under ~/.codex/ambient-suggestions/, despite never knowingly using the feature.

Persistent override

The precise configuration override is:

# ~/.codex/config.toml

[desktop]
ambient-suggestions-enabled = false

Users who want to stop background memory generation while retaining access to existing memories can use:

[memories]
generate_memories = false
use_memories = true

[features]
memories = true
chronicle = false

I verified that:

The configuration parses and persists.
Chronicle reports as disabled.
Memories remains enabled for reading existing memories.
No Chronicle or Computer History process or storage directory was active on this machine.

Restarting the desktop app is advisable because runtime handling appears to vary between builds.
I have not yet completed a controlled before-and-after quota observation. This evidence confirms the invisible enabled default and the exact opt-out syntax; it does not independently establish the amount of quota consumed.

@NellInc

Additional macOS Plus reproduction with precise per-call log evidence

Corroborating this issue with a fully time-boxed reproduction and per-call log evidence.

Environment:

macOS 26.5.1 (Darwin 25.5.0, arm64)
ChatGPT.app version 26.820.60940 (build 7119)
Subscription: ChatGPT Plus

Incident window: 2026-08-26 20:30–23:46 (UTC+8) / 2026-08-26 12:30–15:46 UTC
Observed impact: ~40% of weekly Codex usage consumed with zero chat messages sent during the window.

Root cause confirmed via local desktop logs (~/Library/Logs/com.openai.codex/2026/08/26/codex-desktop-*-t0-i1-063332-0.log): Chronicle was actively running throughout, making real billed model calls (gpt-5.5, reasoning_effort=medium) roughly every 2 minutes:

15:30:48Z  starting codex exec summary session  model=gpt-5.5  reasoning_effort=medium
15:32:29Z  completed summary session → .../chronicle/resources/2026-08-26T09-40-00-...-10min-memory-summary.md
15:33:33Z  starting codex exec summary session
15:34:58Z  starting codex exec summary session
15:36:58Z  starting codex exec summary session
15:38:58Z  starting codex exec summary session
15:40:58Z  starting codex exec summary session
15:42:58Z  starting codex exec summary session
15:45:08Z  starting codex exec summary session
(app-server connection dropped at 15:46:25Z, ending the log)

11 summary-generation calls were started in this window; only 4 completed before the connection dropped (the other 7 were in-flight when the app disconnected). Across the full day, 32 such 10-minute summary files were written to ~/codex/memories/extensions/chronicle/resources/, with bucket timestamps showing this was a backlog catch-up batch spanning screen-recording buckets from Aug 10–13 and Aug 25 — not routine incremental usage from that evening alone.

Confirming the "invisible enabled default" point from @NellInc's comment above: my ~/.codex/config.toml never contained the string chronicle at all (checked via grep against the full file), so it ran on whatever the shipped default is. I had already set ambient-suggestions-enabled = false under [desktop] weeks earlier, which had zero effect on this drain since Chronicle is a separate flag under [features].

Mitigation applied: added

[features]
chronicle = false

and fully quit/relaunched the app (not just closed the window).

Given this is now corroborated across at least 4-5 independent accounts/platforms with matching mechanism (fixed background 10-min summary cadence, real model calls, invisible-by-default), it would help a lot to get an explicit maintainer acknowledgment and a target for making chronicle opt-in by default, plus guidance on requesting quota restoration for windows like this one.

Cross-linking this controlled passive/background-consumption reproduction to #41220, a meta tracker for abnormal Codex usage/quota depletion and usage-accounting inconsistencies. This issue is especially useful because it isolates client state: >103 hours with clients closed showed no drain, launching the desktop app/background activity produced the observed fixed deduction, and quitting stopped it. #41220 is intentionally a symptom-family tracker rather than a claim that every linked report shares one root cause.

Adding a closely matching Plus-account data point from 2026-09-20 (UTC+8).

Important account clarification: this ChatGPT Plus account has never had Pro. A Pro subscription exists on a completely separate OpenAI account, so this case is not a Pro→Plus downgrade or stale Pro-entitlement scenario.

Observed on the Plus account:

No intentional ChatGPT Work or Codex foreground task was run during the relevant period.
The weekly allowance had reset at approximately 00:07 on Sep 20, but by the evening only 21% remained.
The 5-hour allowance showed 0% remaining, with its next reset at 01:11 on Sep 21.
ChatGPT Desktop Analytics nevertheless shows non-zero Codex activity for Sep 20.
Ordinary ChatGPT conversations were in use, but there was no deliberate Work/Codex session that explains the drain.
A local read-only quota-display utility has been used for more than a month without this behavior and is not a recent workflow change.

This looks much closer to the background/ambient activity described in this issue than to an entitlement-change problem.

Could the team please correlate the Sep 20 server-side usage with:

app-initiated pending turns / ambient or personalized suggestions;
background Codex Framework activity in ChatGPT Desktop;
any Computer History / Chronicle-like summarization or other hidden background model calls;
delayed, duplicated, or misattributed quota deductions.

I have screenshots of Settings → Usage and Desktop Analytics showing the 0% 5-hour balance, 21% weekly balance, reset times, and same-day Codex activity, and can provide them through Support if needed.

Follow-up with a stronger timing correlation from 2026-09-21 (UTC+8).

At 11:03 local time the account showed:

5-hour allowance: 94% remaining
UI: “resets in 3 hours”
weekly allowance: 20% remaining (down from 21% the prior evening)

The user still had not intentionally started a Work or Codex foreground task.

Separately, the account's ChatGPT Scheduled tasks executed that morning at:

08:37:31 — daily simulated-investment monitor
08:50:00 — weekly fountain-pen price monitor
09:01:31 — four-Gmail summary
09:45:56 — fountain-pen listing monitor

The active 5-hour window therefore appears to have started in the same morning interval as these automatic Scheduled-task runs. This does not prove which task/surface was charged, but it is a substantially tighter correlation than the prior report.

Please check whether ordinary ChatGPT Scheduled/monitoring tasks (not Codex automations and not user-started Work chats) can currently trigger quota-bearing agentic/Codex-framework work, and whether such consumption is being attributed to the shared Work/Codex allowance. The public Scheduled Tasks documentation says scheduled tasks run in ChatGPT and Codex automations are separate, but it also says model availability and usage limits depend on the task/account/workspace. The user-visible UI does not currently identify which scheduled run consumed the 5-hour/weekly allowance.

A server-side attribution by scheduled-task run ID / surface for the 08:37–09:46 window would be especially useful.

Navigation Menu

Repository navigation

Opening the ChatGPT desktop app silently consumes the Codex weekly limit (fixed 6% per background suggestion run; reproduced under controlled conditions) #37445

Summary

Controlled experiment (2026-08-05 ~ 08-07, KST)

Prior observation of the same fixed cost

Why this is a problem

Expected behavior

Environment

Timeline

Additional macOS Plus reproduction: hidden ambient_suggestions consume quota

Additional default-state and configuration evidence

Persistent override

Additional macOS Plus reproduction with precise per-call log evidence

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Opening the ChatGPT desktop app silently consumes the Codex weekly limit (fixed 6% per background suggestion run; reproduced under controlled conditions) #37445

Description

Summary

Controlled experiment (2026-08-05 ~ 08-07, KST)

Prior observation of the same fixed cost

Why this is a problem

Expected behavior

Environment

Activity

github-actions commented on Aug 7, 2026

Tygb99 commented on Aug 7, 2026

Tygb99 commented on Aug 7, 2026

leadingproblemsolver commented on Aug 7, 2026

Tygb99 commented on Aug 8, 2026

rikyunezumi61-takanoha commented on Aug 10, 2026

Tygb99 commented on Aug 11, 2026

rikyunezumi61-takanoha commented on Aug 12, 2026

Krvislav commented on Aug 20, 2026

Timeline

superwangkezheng-wq commented on Aug 20, 2026

Additional macOS Plus reproduction: hidden ambient_suggestions consume quota

MpMeetPatel commented on Aug 21, 2026

Happypig375 commented on Aug 23, 2026

Tygb99 commented on Aug 24, 2026

Tygb99 commented on Aug 24, 2026

NellInc commented on Aug 24, 2026

Additional default-state and configuration evidence

Persistent override

jason50123 commented on Aug 26, 2026

Additional macOS Plus reproduction with precise per-call log evidence

FromAriel commented on Aug 27, 2026

aieqellery-debug commented on Sep 20, 2026

aieqellery-debug commented on Sep 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions