A secure bridge between AI assistants and your local computer.
Anvaya lets an AI assistant request filesystem actions through a browser extension, but every action is executed locally by a Rust daemon only after explicit user approval. It exposes a small, safe filesystem API — it can never run shell commands, spawn processes, or execute arbitrary code.
Status: Core complete (v0.6). This release is the stable foundation; future integrations and adaptations are left to the community. See
ROADMAP.mdanddocs/Architecture.mdfor how to build on top of Anvaya.
| Component | Linux | macOS | Windows | Notes |
|---|---|---|---|---|
| Rust daemon | ✅ | ✅ | ✅ | Pure tokio::fs/std::fs; no shell |
| Extension popup/options | ✅ | ✅ | ✅ | Any Chrome/Firefox build |
| Approval over extension | ✅ | ✅ | ✅ | Polls 127.0.0.1 over HTTP |
| ChatGPT content script | ✅ | ✅ | ✅ | Site-side, OS-agnostic |
| Gemini content script | ✅ | ✅ | ✅ | Site-side, OS-agnostic |
| Claude content script | ✅ | ✅ | ✅ | Site-side, OS-agnostic |
~ path expansion |
✅ | ✅ | ✅ | HOME on Unix, USERPROFILE on Win |
Path separators are normalized lexically; clients may use / on every OS.
The daemon compiles to a single static binary per target with no extra runtime
dependencies.
Please see docs/HowToUse.md for full instructions on how to install and use the daemon and extension, as well as how to prompt AI assistants to use Anvaya.
For details on the HTTP API, see docs/Architecture.md.
See docs/SECURITY.md. The short version:
- No shell, no process spawning, ever. The daemon only calls
std::fs. - Path traversal is blocked.
..is collapsed lexically and the result must stay under a configured root. - Explicit approval required. Unless
ANVAYA_AUTO_APPROVE=1, every request prompts the operator. - localhost only. The server binds
127.0.0.1.
See ROADMAP.md.
Anvaya is intentionally a core, not a finished product. The interfaces below are stable seams where new functionality plugs in without forking:
-
New filesystem actions. Add a variant to
shared::ActionandActionResponse, implement it indaemon/src/filesystem/ops.rs, dispatch it indaemon/src/actions/mod.rs, expose it at one new HTTP route indaemon/src/api/mod.rs. The approval gate, path policy, and wire envelope pick it up automatically — no other glue. -
New approvers. Implement the
Approverasync trait indaemon/src/permissions/approver.rsand pass it toAppState::newinmain.rs. The defaultExtensionApproverwaits on aoneshotchannel; a futureWryApprover(native desktop window) orSlackApprover(chat approval) drops in the same way. -
New AI chat sites. Add one file in
extension/src/content/sites/(~40 lines) implementingSiteAdapter. Add amatchesFoo()check and acontent_scriptsmatch inmanifest.json. The sharedagent.tsscanner does the parsing; the adapter only finds DOM containers. -
New transports. The daemon's HTTP API is the only surface that knows about Axum. Anything that can
POSTJSON to127.0.0.1:7878works — MCP servers, native messaging hosts, LSP-style assistants, CLI clients. There is no SDK to maintain; thesharedcrate is the contract. -
New tool-call syntaxes. The parser in
extension/src/content/agent.tsonly looks for fenced code blocks labeledanvaya(strict) orjson/empty (candidate, parsed and accepted only if the body'skindmatches a known action). New labels can be added by extendingSTRICT_LABELS/CANDIDATE_LABELS. XML-style tool calls would need a separate parser hook inscanFences. -
Per-agent permissions. Not yet in core. The wire
Requestcarries an optionalreason; a futureagent_idfield plus a per-agent policy table in the daemon'spermissionsmodule would scope which roots/kinds each agent may use, without changing any action or filesystem code.
See docs/Architecture.md for the full module map and dependency direction.
See CONTRIBUTING.md for the bar on security-sensitive changes.
Anvaya is open-source and free to use. If you find it valuable and it saves you time, consider supporting its development!
You can donate via Wise on my website: 👉 flawme.sbs/donate
Dual-licensed under MIT or Apache-2.0, at your option. See LICENSE.
