Symptom
User sees: All 1 account(s) rate-limited for claude. Quota resets in 167h 54m. Add more accounts with opencode auth login or wait and retry.
The watcher does NOT trigger a rotation because the running opencode session has no log file in ~/.local/share/opencode/log/.
Root Cause
The watcher detects rate-limits via two paths:
- Log file scan (
_scan_logs): scans ~/.local/share/opencode/log/*.log for rate-limit patterns
- Accounts check (
_check_accounts_blocked): reads antigravity-accounts.json for rateLimitResetTimes
Problem: When an opencode session is long-running (resumed session, same log file position preloaded), the rate-limit message is written to a log file that the watcher already has a saved position past — or the current session writes to a path that is NOT in the scanned directories.
Confirmed: In a fresh Mac session at 12:35, opencode wrote NO new log file to ~/.local/share/opencode/log/. The newest file there was 2026-03-28T233725.log (from midnight). The watcher had preloaded positions for all existing files, so even if new content was appended it would have been caught — but NO content was appended because the current session wasn't logging.
Actual Detection Path That Should Work But Doesn't (Timing)
The _check_accounts_blocked path reads rateLimitResetTimes from antigravity-accounts.json. The plugin DOES save rateLimitResetTimes to disk via saveToDisk() after markRateLimited(). So in theory the accounts path should catch it.
Root issue: There can be a timing gap between when the plugin marks the account rate-limited (shows error in TUI) and when saveToDisk() completes + the watcher reads the file. If the watcher checked within that window, it misses it.
Evidence
# No log file created for current opencode session (started 12:35):
ls -la ~/.local/share/opencode/log/ | grep '29 März'
# Output: only files from 00:04 and 00:42 - nothing new!
# Account on disk shows clean state (rotation succeeded):
# rateLimitResetTimes: {}
# remainingFraction: 1Fix Required
- Heartbeat/Active poll: Watcher should periodically check via accounts.json for rate-limit state even if no log trigger fires
- Ensure accounts.json write-then-read ordering: Watcher poll interval (8s) may miss transient disk state
- Alternative: Add a dedicated trigger file that the plugin writes atomically when rate-limited
Labels
bug, antigravity, watcher
Symptom
User sees:
All 1 account(s) rate-limited for claude. Quota resets in 167h 54m. Add more accounts withopencode auth loginor wait and retry.The watcher does NOT trigger a rotation because the running opencode session has no log file in
~/.local/share/opencode/log/.Root Cause
The watcher detects rate-limits via two paths:
_scan_logs): scans~/.local/share/opencode/log/*.logfor rate-limit patterns_check_accounts_blocked): readsantigravity-accounts.jsonforrateLimitResetTimesProblem: When an opencode session is long-running (resumed session, same log file position preloaded), the rate-limit message is written to a log file that the watcher already has a saved position past — or the current session writes to a path that is NOT in the scanned directories.
Confirmed: In a fresh Mac session at 12:35, opencode wrote NO new log file to
~/.local/share/opencode/log/. The newest file there was2026-03-28T233725.log(from midnight). The watcher had preloaded positions for all existing files, so even if new content was appended it would have been caught — but NO content was appended because the current session wasn't logging.Actual Detection Path That Should Work But Doesn't (Timing)
The
_check_accounts_blockedpath readsrateLimitResetTimesfromantigravity-accounts.json. The plugin DOES saverateLimitResetTimesto disk viasaveToDisk()aftermarkRateLimited(). So in theory the accounts path should catch it.Root issue: There can be a timing gap between when the plugin marks the account rate-limited (shows error in TUI) and when
saveToDisk()completes + the watcher reads the file. If the watcher checked within that window, it misses it.Evidence
Fix Required
Labels
bug, antigravity, watcher