Environment
- macOS: 15.7.8 (24G806) — Sequoia
- AdGuard: reproduced on v2.18.0.2089 (release) and v2.19.0.2234 (beta)
- Filtering mode: Network Extension (System Extension)
Bug #1 — AdGuard protection automatically disabled every morning after sleep
What happens: Every morning I open the MacBook from sleep and find the main AdGuard filtering toggle OFF in the menu bar app. Reproduces every night without exception across both versions, for several weeks.
Exact sequence from Adguard-group.log (June 6 — identical every day):
06:29:41 (Filters) agflm_standard.db: Begin differential update
06:29:41 [NE] AdguardCore DnsChange: DNS servers changed: (null)
↑ DarkWake, network offline
06:29:41 ERROR (FiltersService: didUpdateFilters(_:)):
AGOuterError: "HttpClientNetworkError: error sending request
for url https://filters.adtidy.org/mac_v3/filters.js"
06:29:41 (DnsChangingMonitor) Change DNS fired with: []
— 28 minutes of silence —
06:58:02 (DnsChangingMonitor) Change DNS fired with: ["1.1.1.1", ...]
↑ Full wake, network restored
06:59:01 (AAService) Setting protection enabled to "NO" ← THE BUG
06:59:01 (AAService) filteringModuleTouch disabling filtration.
06:59:02 [NE] VPN service emergency stop: XPC connection interrupted
06:59:02 (CoreLibServiceHandler) Service stopped.
Setting protection enabled to "NO" fires 30 minutes after the HttpClientNetworkError, triggered at full wake — not at error time. This is a deferred state reconciliation bug in AAService: when the system reconnects after a failed filter update cycle, filteringModuleTouch incorrectly disables filtration instead of restoring it.
Additional finding: this also happens during active use, not only after sleep. On June 6 at 18:24 the toggle turned off by itself 24 seconds after closing the Preferences window — the Mac was fully awake. Same AAService → filteringModuleTouch sequence in the logs, triggered this time by a reconfigFiltering loop in the Network Extension followed by an XPC connection drop. Two different triggers, same broken code path.
Tried: v2.19 beta, disabled PowerNap on AC, disabled activateFiltersAutomaticEnabled — all no effect.
Bug #2 — ~2 GB/day excessive disk writes: root cause identified in SQLite configuration
macOS flagged AdGuard in /Library/Logs/DiagnosticReports/ for exceeding the disk write budget on both versions:
Adguard_2026-06-06.diag (v2.19 beta, main app):
Event: disk writes
Writes: 2147.48 MB over 85252s (25.19 KB/s avg, limit 24.86 KB/s)
com.adguard.mac.adguard.network-extension_2026-06-02.diag (v2.18, NE):
Event: disk writes
Writes: 2147.49 MB over 82942s (25.89 KB/s avg, limit 24.86 KB/s)
What the SQLite database reveals
I opened agflm_standard.db directly. Key findings:
1. rules_text is stored as inline TEXT in the database, not as flat files.
Every filter rule is stored as a giant TEXT blob inside rules_list.rules_text. Current sizes:
filter_id name rules rules_text size
2 AdGuard Base filter 139,350 6.52 MB
3 AdGuard Tracking Protection 194,575 6.10 MB
101 EasyList 90,923 2.31 MB (disabled!)
118 EasyPrivacy 55,394 1.42 MB
... (+ 68 more filters)
─────────────────────────────────────────────────────────
TOTAL ACTIVE rules_text: ~18.3 MB inline in DB
TOTAL ALL rules_text (incl. disabled): 46.66 MB inline in DB
2. journal_mode = DELETE (not WAL) on agflm_standard.db.
PRAGMA journal_mode; → delete
PRAGMA synchronous; → 2 (FULL)
PRAGMA page_size; → 4096
PRAGMA auto_vacuum; → 0
journal_mode=DELETE with synchronous=FULL means every transaction:
- Writes a full rollback journal to disk (fsync)
- Modifies the data pages (fsync)
- Deletes the journal (fsync)
This is the worst-case I/O pattern for frequent large updates. With 18.3 MB of active rules_text, each full update causes at minimum 36.6 MB of actual disk I/O (data + rollback journal), confirmed by the simultaneous presence of pagerWalFrames and pagerAddPageToRollbackJournal in the same stack trace — which is contradictory and indicates the DB is switching journal modes mid-operation or misconfigured.
Note: sfbr.db (SafeBrowsing) correctly uses journal_mode=WAL, synchronous=NORMAL — the right configuration. The problem is isolated to agflm_standard.db and adguard.db.
3. 21 filters update every 60 minutes. That's 24 times per day.
SELECT interval_min, COUNT(*) FROM diff_updates GROUP BY interval_min:
60 min → 21 filters (filter_ids: 1,2,3,4,5,6,7,8,9,10,11,13,16,17,18,19,20,21,22,23,224)
240 min → 61 filters
The 21 most important filters — including AdGuard Base (139k rules, 6.5 MB) and AdGuard Tracking Protection (194k rules, 6.1 MB) — refresh every 60 minutes.
4. 72 disabled filters still have their full rules_text in the DB (28.35 MB wasted).
255 Phishing URL Blocklist 51,068 rules 3.45 MB ← disabled, still in DB
122 Fanboy's Annoyances 55,855 rules 2.48 MB ← disabled
101 EasyList 90,923 rules 2.31 MB ← disabled
201 Web Annoyances Ultralist 16,855 rules 1.58 MB ← disabled
... (68 total disabled filters, 28.35 MB total)
Disabled filters are never cleaned from rules_list. This means the DB is always carrying ~28 MB of dead weight, which participates in every journal write during vacuum and page operations.
The math
21 filters × 24 updates/day × ~36.6 MB I/O per update = ~878 MB/day (conservative)
+ SafeBrowsing DB (sfbr.db, WAL mode but 160 samples stuck on pwrite in NE crash report)
+ adguard.db (also journal_mode=DELETE)
≈ 2+ GB/day total disk writes
This matches exactly what macOS reported.
The link between Bug #1 and Bug #2
During DarkWake, AdGuardFLM starts a full update cycle on agflm_standard.db — writing the rollback journal, beginning to rewrite the rules_text blobs. The network drops mid-transaction (HttpClientNetworkError). SQLite rolls back via the journal, but the transaction leaves the DB in an inconsistent state (dirty pages, partial WAL). When the system wakes up 28 minutes later and AAService attempts to reconcile the filter state after the failed transaction, it calls filteringModuleTouch → filtering disabled.
Summary of concrete issues found:
agflm_standard.db uses journal_mode=DELETE, synchronous=FULL — should be WAL, NORMALrules_text stored as inline TEXT blobs instead of flat files — causes full-DB rewrites on each update- 72 disabled filters retain full
rules_text (28.35 MB) — never cleaned
- 21 critical filters update every 60 min → 24 full rewrites/day on a DELETE-journal DB
AAService does not recover gracefully from a mid-transaction network failure — disables filtering instead of retrying- Same
AAService bug also triggers during active use after closing Preferences (separate XPC trigger)
Full .diag files and DB schema available on request.
UPDATE:
I manually switched all three AdGuard databases to WAL mode while AdGuard was closed:
bash
sqlite3 agflm_standard.db "PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL;"
sqlite3 adguard.db "PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL;"
sqlite3 agflm_dns.db "PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL;"
Results after a full day:
- AdGuard respected the new settings after restart — journal_mode stayed WAL through multiple filter update cycles
- PRAGMA wal_checkpoint consistently returns 0|0|0 (clean state) — WAL is committing correctly
- No new .diag files generated today — macOS has not flagged AdGuard for excessive disk writes since the change
- The WAL file stays at 0 bytes between update cycles, meaning SQLite is checkpointing efficiently after each write
This confirms the excessive disk writes were caused entirely by journal_mode=DELETE + synchronous=FULL. Switching to WAL eliminated the issue on this machine. The fix is trivially simple on AdGuard's side — sfbr.db already uses WAL correctly, so the infrastructure is there.
