Ankita v2.4.3：在聊天窗口旁加入可操控的实时浏览器

I've been building Ankita — an open-source desktop AI assistant — since I was 16. Version 2.4.3 is out today, and its headline feature is one I've wanted from the start: a real browser that lives next to your chat, which the assistant can actually drive. A live browser beside chat Ankita can already do a lot on your machine — run commands, edit files, manage MCP servers — but until now, the web was read-only territory. v2.4.3 changes that with a browser stage built into the desktop app: you see the tabs, the URL, the page status, and the current page, with Stop and Take control buttons. The assistant can open pages, read snapshots of what's on them, click, type, scroll, and fill forms — all through a set of browser tools that load on demand through Ankita's existing tool-discovery system (which I wrote about in my last post), so the browser capability doesn't bloat the system prompt until you actually need it. One detail I like: browser fill_form fills up to ten fields from a single page snapshot, and it works with selects and checkboxes as well as text fields. Password values stay hidden from the model — the snapshot deliberately redacts them — and the approval previews redact entered text, so typing credentials through the assistant doesn't leak them into the conversation view. Two backends, both opt-in There are two browser plugins, and both start disabled — you choose: Playwright Browser uses its own separate Chromium profile, so the assistant never touches your personal browser session. Chrome local connects to Chrome through a pinned Chrome DevTools MCP server, with options for a private session, a debug port, or your own session. Desktop setup covers Chromium download progress, a background mode, and a debug-port connection test. Every plugin gets allowed and blocked domain lists, and navigation is HTTP/HTTPS only — private hosts are blocked by default. Browser actions (clicks, form submissions) require approval; reading pages doesn't. That asymmetry was deliberate: I want the assistant to look things up freely but never mutate a page without the owner saying yes. Clicks and form submissions are also never automatically replayed after a connection hiccup — if a recovery path can't prove what happened, it asks instead of retrying blindly. The unglamorous work: performance and filesystem security Half of this release is the kind of work nobody notices, which is exactly the point. On Windows, command creation, shell discovery, and process-tree work now run in a worker, because slow native startup could block the owner's event loop. File inspection reuses a resident worker instead of spawning one per call — a local 30-call README sample measured a 3.37 ms warm median after startup. Terminal Markdown redraws coalesce on a fixed 20 ms deadline, and history trimming now measures costs incrementally instead of re-scanning the whole conversation. On the security side: file tools now enforce the workspace boundary for absolute and relative paths, including Git inventories — rejecting traversal escapes, interior symlinks/junctions, Windows device aliases, and alternate data streams. Atomic writes use exclusive, unpredictable staging files. Approval fallbacks and MCP diagnostics redact recognizable credentials and secrets from env vars, config files, server settings, and headers. Verified, not just shipped The release notes for v2.4.3 run long because the verification runs long too: the clean GitHub Windows release run passed 713 tests with 0 failures, the packaged desktop executable was exercised against a disposable local HTTP/SSE model fixture (appearance switching, browser submission, screenshot pixels, takeover, Stop, command stdin/EOF), and all four published assets had their SHA-256 digests checked. There's an audit verification record and a browser guide if you want the full story. Try it Grab it from the releases page — there's a portable build if you don't want to install anything. If you enable the browser plugins and find a workflow where approval-vs-autonomy feels wrong, I'd genuinely like to hear about it. That boundary is the hardest design question in this whole project, and I'm still learning where it should sit.