Feature: Local filesystem connector / desktop app for Claude‑style “Computer Use”

[egouilliard-leyton]

I would love to use Onyx more like Claude’s “Computer / Cowork” mode: an AI agent that can work directly with files on my local machine, not just cloud connectors.

Today, Onyx’s connectors focus on SaaS and cloud sources (Google Drive, GitHub, Notion, Confluence, etc.), which is great for shared knowledge, but there is no way to point Onyx at an arbitrary local folder or project tree on a developer’s laptop or workstation. This makes it harder to use Onyx for workflows like deep codebase assistance, doc refactors, or local data analysis where content never leaves the machine or isn’t synced to a cloud storage.

Proposed feature

Add support for a “local filesystem connector” (or an official desktop app) that allows Onyx to index and interact with files on a user’s computer, with explicit, opt‑in scoping and strong security guarantees.

Concretely, this could look like:

A small desktop agent (macOS / Windows / Linux) that:

Lets the user select specific folders to expose to Onyx (e.g. ~/projects/my‑repo, ~/Documents/ClientA).

Builds and maintains a local index of those files (code, markdown, PDFs, office docs, etc.).

Exposes a secure local API / tunnel that the Onyx server can use to search and retrieve chunks when answering queries for that user.

Alternatively, a local connector service that self‑hosted Onyx deployments can run next to the data, configured via environment variables or admin UI, which:

Mounts one or more paths on disk and treats them like any other connector source.

Enforces per‑user or per‑group ACLs at the connector level (for multi‑user environments).

Integration with the existing search and chat flows, so that:

Local files appear as a normal “source” filter alongside Drive, GitHub, etc.

Chat answers can be grounded in local files via RAG, with citations back to local paths.

Motivation / Use cases

Some examples where this would be extremely valuable:

Working with local monorepos or private codebases that are not on GitHub / GitLab or cannot be pushed to any third‑party service.

Doing large‑scale refactors or reviews where the AI needs to see the entire project structure and multiple files at once.

Assisting with local datasets, exports, or one‑off client folders that live only on disk, not in Google Drive or SharePoint.

Security‑sensitive environments where teams want to self‑host Onyx and keep all raw data on their own infrastructure, including developer workstations or on‑prem file servers.

Claude Desktop plus the Model Context Protocol (MCP) already supports a pattern where a local tool server gives the model controlled access to the filesystem; having an analogous capability in Onyx would make it a much more compelling “AI coworker” for engineering teams and power users.