Ankita v2.5.0: a desktop companion island that never misses an approval

Version 2.5.0 of Ankita — my open-source desktop AI assistant — shipped yesterday. The headline feature is a companion "island" that lives on the top edge of the screen, driven by the assistant's real threads, tools and approval flows. But the change I'm proudest of is invisible: MCP tool calls now go through a four-level approval gate where a heuristic can suggest but never deny, and no scheduled job can quietly loosen its own protection.

The island: real state, not a widget

The island (368px wide, in compact/expanded/petit modes, plus a 14px wake strip to peek it back out) shows up to four teammate mascots in an activity grid. It is not a second UI bolted on — it subscribes to the same underlying state the chat window uses. Approvals that arrive while the main window is minimised still surface; restoring or minimising keeps the same draft and companion window.

The mechanism worth knowing about: the approval registry stores pending requests on entry so late subscribers (like the island) can pick up what was asked while they weren't listening. Activity rolls upward instead of needing a history scrollbar.

I'll be honest: my own build-in-public teaser post last week (before this shipped) got almost no traction on dev.to. Fair enough — the audience wants shipped code, and this is shipped. 931 tests ran on the Windows release workflow: 899 passed, 32 skipped, 0 failed, plus nine grouped native checks against the unpacked runtime covering real file tools, approval flows, capture pairing and project surfaces.

A mascot that eats your files

File capture got character: drop a supported file on the selected mascot and it opens its mouth, swallows, and visibly chews while the document reader works, then reacts to success or failure. Both desktop and island use the existing document/image readers, and attachments stay with their original teammate. Reduced-motion settings skip the swallow animation entirely. It is silly, but it is also a genuine affordance — the animation is the progress indicator.

Capture from the browser, without trusting the browser

A second companion piece: a Chrome/Edge MV3 helper extension that captures readable page text when you drop the mascot onto an HTTP/HTTPS page. The interesting part is the pairing design:

• Pairing runs over the desktop's authenticated loopback bridge with single-use drag tickets — replayed, expired or cancelled tickets are rejected, and pairing survives browser restarts.
• Captures preserve existing drafts, queue in an inbox when attachment slots are full, and never trigger a model request automatically. The extension ships in the package, is loaded unpacked separately, and is not store-published.

This is deliberately paranoid, and I'd rather have paranoid here: a tool that reaches into your browser is exactly the thing that should not silently act.

Keyless Composio sign-in: nothing to host, nothing to leak

Connecting an app used to mean an API key in an env var. v2.5.0 replaces that with a browser OAuth 2.1 + PKCE flow: discovery, dynamic client registration as a public client (no secret issued), a single-use http://127.0.0.1:<port>/callback loopback redirect, and a PKCE S256 code exchange. No public callback URL, no domain, no certificate, no broker to stand up.

The credential hygiene part: the access token is written to the OS vault; the grant file holds only a grantId, endpoints, apps and timestamps — never the token, verifier or refresh token. Revoking deletes both in one step. The old COMPOSIO_API_KEY and COMPOSIO_BROKER_URL paths keep working until the deprecation window closes.

MCP approval tiers: the heuristic can never deny

Previously, a connection's trusted flag could skip the approval gate — a read-only-hint rule with a bypass. That is now gone. Tool calls resolve a four-level tier:

blocklist → explicit tool rule → per-app rule → locked app defaults → heuristic

Auto-allow, ask once, always ask, deny. Composio meta-tools are classified by the worst action they enclose — so COMPOSIO_MULTI_EXECUTE_TOOL wrapping GMAIL_SEND_EMAIL always asks, while read-only catalog discovery stays frictionless. gmail ships locked to always ask out of the box.

Two design choices I want to be explicit about, because they're the ones someone could reasonably disagree with:

1. A heuristic can never deny. The last resolution step can recommend allow, ask or ask-once, but never deny. The reasoning: heuristics are fuzzy, and a fuzzy rule silently dropping tool calls would make the agent look stupid and untrustworthy. Denials must be explicit and auditable.
2. Loosening is refusal-guarded. The new composio tiers, allow, always and deny actions inspect and change the gate — but a call that lowers protection can never run under auto-approve. An unattended scheduled job cannot quietly grant itself a lower tier for every later session. Overrides persist to mcp-tiers.json alongside allowed/asked/denied counters.

Also in 2.5.0

• Project sections — Overview, Tasks and Context organize folders, assignments, rules, open/completed tasks and searchable note/decision records, with per-project draft retention.
• Saved sign-ins becomes a first-class browser-vault section with a live count, per-row Remove actions and loading/empty/error states.
• The main desktop shell was rebuilt in the island's graphite style with a compact navigation rail; completed Markdown replies are memoized instead of reparsed per streaming token.

One design question, genuinely

The tier system errs toward keeping the gate shut: gmail is locked to always-ask, heuristics can't deny, and you can't loosen anything from an unattended context. I chose this because the failure mode I fear most is a scheduled job quietly downgrading its own protection at 3am. But is it too paternal? Should a power user be able to permanently declare "auto-allow everything gmail does" — or is that declaration exactly the thing that should never be easy to make?

I'd rather be argued with than congratulated. The repo is akyourowngames/A.N.K.I.T.A, the full release notes are on the v2.5.0 tag, and issues/PRs from people who've built their own approval gates are the most useful kind of feedback I can get.