Review of "Agent Usage Indicator" version 6

Details Page Preview

Shows the remaining Codex, Claude and Antigravity usage limits in the top bar, using the login of each provider's command-line tool. For each enabled provider: - Codex: runs the installed codex app-server and asks it for account and rate-limit data. - Claude: reads the Claude Code login in ~/.claude/.credentials.json and requests the profile and usage from api.anthropic.com. When that login has expired, it runs claude doctor once, which renews it. - Antigravity: runs the installed agy --version and agy -p /usage. The extension does not write credentials and contacts no other service. Codex, Claude and Antigravity are trademarks of OpenAI, Anthropic and Google. This extension is not affiliated with or endorsed by them; their names and logos only identify each service.

Extension Homepage
https://gitlab.com/bruno.englert/gnome-extension-codex-limit-indicator

No comments.

Diff Against

Files

Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.

Shexli (experimental)

Shexli did not find any issues.

All Versions

Version Status
10 Active
9 Rejected
8 Rejected
7 Rejected
6 Rejected
5 Rejected
4 Rejected
3 Inactive
2 Inactive
1 Rejected

Previous Reviews on this Version

JustPerfection rejected
Still seems you aren't cleanup any of those timeouts in `providers/codex/appServer.js` on disable/destroy.
brunoenglert posted a review
Hey, I think there's a misunderstanding. There is cleanup: In `providers/codex/appServer.js`, `destroy()` starts at line 256. The two paths are: - Request timeouts: `destroy()` → `_rejectPending()` → `_rejectRequest()` → `_takePending()`. The actual `GLib.Source.remove(entry.timeoutId)` is at line 434. - Stderr-drain timeout: `destroy()` → `_failConnection()` → `finishStderrDrain()`. That callback removes `connection.stderrDrainId` at line 574. Having said that, there are way too many indirections, so I think I'll refactor this in the future version to make it much simpler.
JustPerfection posted a review
It should be clear for the reviewers that the timeouts getting removed on destroy and before creating a new one. Trace back 4 steps to find the timeout removal isn't really a good approach. When one of them get removed in the future update, you can break the chain and we can miss it in the diff.