What omnifs is

omnifs is a projected filesystem for APIs and data sources.

It mounts API-backed resources under local paths. Providers project APIs and data sources into directories, files, rendered views, and trees.

cat /omnifs/github/0xff-ai/omnifs/issues/open/42/title
cat /omnifs/linear/teams/ENG/issues/open/ENG-204/state
cat /omnifs/docker/containers/by-name/postgres/state
cat /omnifs/arxiv/papers/1706.03762/paper.json | jq .title
cat /omnifs/dns/example.com/MX

The provider interface is designed for systems with APIs, sockets, repositories, databases, object stores, and control planes. Use the provider catalogue for documented path surfaces.

The problem

Operational workflows usually cross system boundaries. Repos live in GitHub. Tickets live in Linear. Runtime state lives in Docker or Kubernetes. Research lives in arXiv. Data lives in databases. Production context lives in logs, queues, cloud APIs, billing systems, docs, and internal tools.

Each system asks consumers to learn another SDK, auth flow, pagination model, retry policy, rate limit, and response shape. omnifs moves that integration work into providers and exposes the projected state through the filesystem.

The practical result is a common access path for existing tools:

• ls to discover mounted resources,
• cat and jq to inspect structured records,
• grep, rg, and find to search across mounted resources,
• diff, tar, rsync, and editors for file-oriented workflows,
• agents that can follow paths instead of embedding a client for each service.

Read model

omnifs defines a filesystem interface over API-backed resources and data sources.

Read operations are the supported operation class. They establish the namespace, provider boundary, cache model, auth boundary, and shell compatibility surface. Planned write flows should keep the path-shaped interface while making mutation intent explicit and reviewable.

A provider should not be read as an SDK wrapper. It defines a path shape for a domain while exposing that domain through the same filesystem interface.

Provider catalogue

Use the provider catalogue for documented providers, mount prefixes, path families, auth notes, and examples. This page describes the model, not a provider inventory.

The runtime FUSE mount is Linux. On macOS, omnifs runs the Linux runtime in a Docker container and you read paths through omnifs shell. Native non-Linux mounts are outside the supported runtime path.

How it works

omnifs has three main pieces:

Piece	Responsibility
Host runtime	Owns FUSE, provider lifecycle, credentials, cache, callouts, runtime grants, and the container session.
Provider	Projects one API or data source into paths, objects, fields, rendered views, and trees.
Mount	Binds one provider instance to a path prefix such as /github, /docker, or /db.

A provider is a wasm32-wasip2 component. It does not receive ambient network, disk, Docker, Git, or credential access. It returns provider steps to the host. A step may suspend with callouts for the host to authorize and execute, or complete with a result and effects for the host to commit.

The provider owns the projection shape. The host owns authority, credentials, cache, callouts, and filesystem behavior.

What it is not

omnifs is not an SDK wrapper around every service API. It is not a background sync tool that mirrors whole services into a local folder. It is not an ETL pipeline. It is not an MCP-only tool surface.

Its role is narrower: make APIs and data sources legible as filesystem paths, keep authority in the host, and let existing tools operate against the resulting namespace. MCP-style tools expose named actions to agents. omnifs exposes resources as paths that filesystem-aware processes can traverse, inspect, cache, pipe, and replay.

Next

• Read Why paths for the design argument behind the interface.
• Read Use cases for concrete usage patterns.
• Read Architecture for the host, provider, cache, and authority model.
• Read Security model for the authority boundary.