# Changelog All notable changes to this project are documented here. The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and the project uses [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ## [0.1.6] - 2026-09-24 ### Fixed - A rate-limit answer asking to retry after hours could stop polling for that long; `Retry-After` is now honoured only up to the 30-minute backoff cap. - Launching the app a second time while the first instance was still starting could do nothing at all; the second launch's request to show the flyout is now kept until the first instance is ready for it. - A Claude Code CLI refresh that timed out could leave an unobserved error behind in the background. - The release zip's README described the pre-0.1.3 behaviour: it now mentions the automatic token refresh, Start with Windows being on by default, the weekly update check and the two registry values the app writes. ## [0.1.5] - 2026-09-22 ### Fixed - Using only the Claude Desktop app left the percentages frozen: the access token in Claude Code's credentials file lives about eight hours and only the Claude Code CLI renews it, while the Desktop app signs in on its own and the Claude Code it hosts gets its token from the Desktop app, so the file went stale and every poll and manual refresh reported an expired sign-in until the CLI happened to be started. The app now starts the CLI once in the background when the token has expired (print mode with its input closed, so it renews the sign-in and exits without sending a prompt, starting an MCP server or writing a session file), reads the file again and carries on. The attempt is throttled to one per minute, killed after ten seconds, and never touches the file or an OAuth endpoint itself. It finds the CLI on PATH or, failing that, the build bundled with Claude Desktop, and says so when neither exists. - The expired and signed-out messages now say to run the Claude Code CLI instead of "open Claude Code", which opening the Desktop app does not satisfy. ## [0.1.4] - 2026-09-15 ### Fixed - With monitors at different scaling (a 200 % laptop screen beside 100 % displays), or after reconnecting monitors, the flyout could open half its width and as tall as the screen, with the Refresh and Settings buttons stretched to fill it, and stay that way until the app was restarted. Moving to a monitor with another DPI made Windows rescale the window, which WPF applies as a manual resize: the width was halved and the height stopped following the content. The flyout now steps onto the target monitor before measuring itself, puts its width and content-driven height back before every placement and after every DPI change, ignores the resize events its own placement causes instead of re-placing in a loop, and stays anchored to the icon it was opened from rather than to wherever the cursor is when the DPI changes. ## [0.1.3] - 2026-09-10 ### Added - The app now starts with Windows by default. The first launch creates the per-user startup entry and records that it has done so, so it happens exactly once: clear **Start with Windows** and it stays cleared. Nothing is elevated, and the entry is still the same `ClaudeUsageTray` value under `HKCU\Software\Microsoft\Windows\CurrentVersion\Run` it always was. ### Changed - **Start with Windows** has moved to a **Startup** section at the top of the Settings window, where it is the first thing you see, instead of sitting inside **Tray icon**. The note beside it now appears only when Windows refuses the change. - The startup entry sits behind an `IAutostartEntry` interface, so the behaviour around it is covered by tests that never touch the real registry. ### Fixed - A damaged `history.db` stopped everything that reads it: every session-log scan failed and the flyout's charts froze on stale data, which looked like history not being saved at all (`database disk image is malformed` in the log). The app now checks the file once at start; a damaged one is set aside as `history.corrupt-