chattymin/PokeTokenBar

LocalAdditionalUsageReader.kiroEntries (Sources/PokeTokenBar/Core/LocalAdditionalUsageProvider.swift:800) re-reads and re-parses every stored Kiro conversation on every poll. Unlike the Cursor and Copilot readers, it has no watermark to advance — Kiro rewrites a conversation's whole history JSON in place on each turn and deletes turns outright on /clear, so there is no monotonic row id to resume from. That was the right call for #170; the cost of it is what this issue is about. Measured here on a synthetic database of 30 conversations x 80 turns (user 500 B, assistant 2 KB per turn), 6.3 MB on disk: rescan : 209–360 ms (2400 entries) empty window : 37 ms (0 entries, `modifiedSince` past every turn) The 37 ms floor is the point: modifiedSince is applied inside kiroTurnEntries (:860), after the row has been read out of SQLite and jsonObject has parsed it. Narrowing the window skips entry construction, not the read or the parse. In normal operation since is the s

Every provider resolves its log location on its own, and only Claude can be pointed somewhere else from inside the app. #162 adds a settings field for extra Claude scan folders; this issue tracks extending that to the rest. Where each provider looks today Provider Location Override Claude computed multi-root CLAUDE_CONFIG_DIR + settings field (#162) OpenCode ~/.local/share/opencode OPENCODE_DATA_DIR Hermes ~/.hermes HERMES_HOME Copilot ~/.copilot COPILOT_HOME Grok ~/.grok/sessions GROK_HOME Codex ~/.codex/sessions none Gemini ~/.gemini/tmp none Antigravity ~/.gemini/antigravity-cli/conversations none Cursor ~/Library/Application Support/Cursor/User/globalStorage none Environment overrides are now read through the login shell (#176), so they work from a GUI-launched .app. What remains is that four providers have no override at all, and that an environment variable is an awkward thing to ask a menu bar app's user for. Why this is worth doing The failure mode is

UpdateChecker.applyUpdate() calls NSApp.terminate(nil) (UpdateChecker.swift:66), which ends the instance whose popover was used. The detached script then waits for the app to be gone (UpdateChecker.swift:123): for i in $(seq 1 40); do pgrep -x PokeTokenBar >/dev/null 2>&1 || break; sleep 0.5; done pgrep -x matches on process name, so it matches any instance. With one instance the loop breaks in well under a second, which is the case it was written for. With two, it can never break: the surviving instance keeps the name alive, so the wait always burns its full 20s and falls through. Two things then follow, both of which the wait was there to prevent (:116): brew upgrade --cask replaces the bundle underneath a still-running app — the bundle-replacement race the loop was added to avoid. launchctl kickstart -k (:130) starts a new instance. If the survivor is the launchd job's process, -k replaces it and the update comes up. If the survivor is the GUI-launched one — which is the case w

AppLog.write hands the line to a background queue (AppLog.swift:28) and returns. When the caller is on its way out of the process, the line races the teardown and is frequently lost. The site that matters today is CrashReporter.markClean() (CrashReporter.swift:65-68), which runs from the NSApplication.willTerminateNotification observer registered in install() (:45-47). AppKit posts that notification and then exits, so clean shutdown is written only if the log queue happens to get scheduled first. Measured with an AppKit app reproducing the sequence — enqueue on a serial DispatchQueue, then NSApp.terminate(nil): runs=100 landed=58 lost=42 Consistent with what is on disk here: the current 1.2M PokeTokenBar.log has 1 launch: line and 0 clean shutdown lines; the rotated 2.0M PokeTokenBar.old.log has 1 and 1. The consequence is not just a missing line. clean shutdown is the human-readable half of the shutdown record, so the log reads as if sessions end abruptly even when they don't. The

What startOutsideClickMonitor() (Sources/PokeTokenBar/PokeTokenBarApp.swift:375) overwrites outsideClickMonitor without removing whatever token is already stored: private func startOutsideClickMonitor() { outsideClickMonitor = NSEvent.addGlobalMonitorForEvents(matching: [.leftMouseDown, .rightMouseDown]) { ... } } Start and stop are not symmetric either: registration happens at the call site (togglePopover(), PokeTokenBarApp.swift:360) while removal happens in the delegate callback (popoverDidClose, :368). Why it matters Nothing is broken today. togglePopover() is the only path that calls popover.show, and openPopover() (:336) guards on popover.isShown, so the monitor cannot be registered twice. The point is what happens when a second show path is added: the previous token is dropped on the floor, NSEvent.removeMonitor is never called for it, and a global mouse monitor stays installed for the rest of the process — outliving the popover it was meant to track. That failure is silen