omnifs: access the world through your filesystem
DOCS GITHUB↗ CONTACT↗
/omnifs ✕<br>DOCS↗ GITHUB↗ CONTACT↗<br>/intro<br>/OMNIFS /OMNIFS<br>open a /path, read the world.<br>omnifs lets you access the world through your filesystem. APIs and data sources become files and directories you can ls, cat, grep, pipe, and hand to an agent.<br>The omnifs host handles the hard parts: filesystem protocols, caching, auth, network access, pagination, and rate limits. You attach new systems by writing lightweight Wasm providers with the omnifs SDK.
omnifs shell<br># read GitHub as files<br># issues are files: list, count, grep, cat<br>/ $ ls /github/0xff-ai/omnifs<br>actions issues pulls repo<br>/ $ ls /github/0xff-ai/omnifs/issues/open | wc -l<br>47<br>/ $ grep -rl "ROCm" /github/0xff-ai/omnifs/issues/open<br>/github/0xff-ai/omnifs/issues/open/1432/body<br>/github/0xff-ai/omnifs/issues/open/1450/body<br>/ $ cat /github/0xff-ai/omnifs/issues/open/1432/title<br>Crash on long context with quantized model
The omnifs host handles the hard parts: filesystem protocols, caching, auth, network access, pagination, and rate limits. You attach new systems by writing lightweight Wasm providers with the omnifs SDK.
quickstart<br>01 $npm install -g @0xff-ai/omnifs<br>02 $omnifs setup<br>03 $omnifs up && omnifs shell<br>04 $ls /github
docsproviderssdksource
every system already speaks omnifs catlsgrep -rfindtail -fjqrsynctarvimdiffxargsheadwcmd5sum cat ls grep -r find tail -f jq rsync tar vim diff xargs head wc md5sum
/glue<br>One namespace to access everything.<br>APIs made systems and platforms programmable, but they did not give us a shared substrate. In fact, they encouraged fragmentation.<br>Each service exposes its own API, schema, auth model, terminology, error table, pagination rules, rate limits. Often, each requires a dedicated SDK.<br>Conversely, the filesystem is the most durable interface in computing. Every program, agent, language masters disk and file I/O. Semantics are strict and universally understood, and /filesystem/paths offer hierarchical addressing.<br>today, per vendor ts<br>const octokit = new Octokit({ auth })<br>const { data } = await octokit.rest<br>.issues.get({ owner, repo, issue_number })<br>console.log(data.title)<br>// + install the sdk<br>// + implement the auth flow<br>// + paginate, retry, rate-limit<br>// + repeat for every other vendor
with omnifs<br>/ $ cat /github/0xff-ai/omnifs/issues/open/56/title<br>Implement object cache before provider SDK polish
How does omnifs relate to MCP? MCP gives models tools to call. omnifs gives them API-backed resources as paths. A path can be traversed, grepped, diffed, cached, and piped to any other process.
/paths<br>Paths are the unified interface.<br>/omnifs mounts systems, services, data sources (really, anything), onto the local filesystem. Instead of teaching humans, agents, and programs how to deal with every API, they can all rely on the same stable interface we've known and loved for decades: files and directories.<br>Every provider translates its service into directories, files, fields, rendered views, and searchable trees.<br>The common layer is not a universal schema. The common layer is the filesystem: paths that humans, scripts, agents, caches, and traces can all operate on without learning the upstream API.<br>/github provider<br>/ollama owner<br>/ollama repo<br>/issues collection<br>/open filter<br>/12959 object<br>/title field
/linear provider<br>/teams scope<br>/ENG team<br>/issues collection<br>/open filter<br>/ENG-204 object<br>/state field
/docker provider<br>/containers collection<br>/by-name index<br>/api object<br>/state field
/pipe<br>Pipe data and state across systems.<br>Once services share a filesystem substrate, pipes can cross system boundaries. Read a CI run, inspect a container, grep the ticket queue, or sketch new providers for the systems you wish were files.<br>edge forensicswaf × dnsrelease attributionincident × commitmodel provenancepaper × model cardpayments reconciliationprocessor × database<br># provider sketch<br>$ cat /cloudflare/zones/0xff.ai/firewall/events/latest/client_ip \<br>| xargs -I% cat /dns/reverse/%<br>census-12.shodan.iocloudflarenextdns
# sketched Slack path, live GitHub issue leaf<br>$ cat /slack/channels/incidents/@last/metadata/release_issue \<br>| xargs -I% cat /github/0xff-ai/api/issues/all/%/user<br>[email protected]slacknextgithub
# live arxiv, sketched huggingface<br>$ cat /arxiv/papers/1706.03762/paper.json | jq -r .title<br>Attention Is All You Need<br>$ grep -l 1706.03762 /huggingface/models/*/*/README.md<br>/huggingface/models/google-t5/t5-base/README.mdarxivhuggingfacenext
# sketched Stripe path, live db leaf<br>$ cat /stripe/charges/ch_3PqZ8/metadata/order_id \<br>| xargs -I% cat /db/tables/orders/%/data.json | jq -r .status<br>paidstripenextdb
/providers<br>A growing pool of providers.<br>The provider catalogue is the source of truth for documented provider path surfaces. Providers are the extension point: if a system has an API, socket, repository, database, object store, or control plane, it can have a path.<br>/ github issues, PRs, CI, and repo trees reposissuesPRsCI runsrepo tree...