Launcher and editor extension

Two local tools exist for one reason: code sync follows the local filesystem. A remote connection to Wexa can read a repository that has already been synchronised, but it cannot see the file you edited thirty seconds ago and have not committed. Something has to run on the machine where the code lives.

That something is the fabric-sync daemon. The two tools on this page are the two supported ways of getting it running and keeping it running.

Both are built from the Wexa repository. Neither is on a public registry today.

What gets kept synchronised

Both tools drive the same daemon, so both keep the same thing in step: your local git working tree, mirrored into the project's code graph — the files, the symbols in them, and the calls between those symbols. That is what search-code and fetch-code read.

Three properties are worth being precise about, because they are what distinguish local sync from the alternatives:

• Uncommitted edits are included. The daemon watches the working tree, not the last commit. This is the whole reason it exists.
• Deletions are propagated. A removed file is tombstoned rather than left behind as a stale symbol that an agent will keep finding.
• Branch and commit are stamped. The graph records which branch and which revision each state came from.

Git hooks — post-commit, post-checkout, post-merge, post-rewrite — wake the daemon on the events a file watcher alone would handle poorly, such as a branch switch that changes a thousand files at once.

Registration state lives in .fabric/sync.json at the repository root, which is added to .gitignore automatically because it is machine-local rather than project-wide.

Wexa Connect

fabric-connect is a launcher. Configured as the command for a tool session, it registers the checkout, starts or reuses the fabric-sync daemon, queues a catch-up ingest, and only then proxies the session through to the gateway. Connecting and synchronising become one action instead of two, which matters because the failure mode of doing them separately is silent: the session works, the answers are just out of date.

cd tools/fabric-connect
npm install && npm run build
npm link                 # puts `fabric-connect` on PATH

Point a client's server configuration at it:

{
  "mcpServers": {
    "fabric": {
      "command": "fabric-connect",
      "args": [],
      "env": {
        "FABRIC_GATEWAY_URL": "https://fabric.wexa.ai",
        "FABRIC_SYNC_TOKEN": "<oauth-or-bootstrap-bearer>"
      }
    }
  }
}

If the repository has already been registered — by the editor extension, for instance — the token can be omitted and the launcher reads .fabric/sync.json.

Sync without a session

fabric-connect sync --cwd /path/to/repo

This supervises the daemon and nothing else. It is the right command for a build machine that should keep a checkout synchronised without any agent attached to it.

Short-lived tokens for a remote machine

An agent editing files on a different machine needs the daemon running there. Mint a short-lived credential for it:

curl -s -X POST "$BASE/v1/codesync/bootstrap" \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"repo_name":"acme/app","ttl_seconds":900}'

The response carries an access token, the connector id and the session URL. There is no refresh token: the credential is deliberately short-lived, because it is going onto a machine you are not sitting at.

Codegraph, the editor extension

Codegraph — powered by Wexa, version 0.4.2, publisher WexaAI, requires VS Code 1.85 or later. It installs into VS Code and its forks: Cursor, Windsurf, VSCodium, Trae and Positron are all handled by the repository's install-all.sh.

It activates when a folder contains .git or an existing .fabric/sync.json, so opening a repository is enough to be offered a connection.

Connecting a repository

Sign in with your Wexa identity, pick a project, then pick or auto-create the connector for the codebase. Your organization comes from the sign-in token and is never typed — which means you cannot accidentally register a repository against an organization you do not belong to, and a token from another organization is rejected in any case. The extension then writes .fabric/sync.json, installs the git hooks, and starts the first ingest.

The token only offers projects your role can reach, so the picker is a view of your real access rather than a list you might be refused from later.

After connecting

The Codegraph panel in the activity bar shows live sync status per repository — branch, element count, errors — and one shared connection card naming the organization, department, project and connector, each with a change button. It is shown once rather than per repository, because the machine holds a single Wexa identity. The status bar carries the same state in one word: synced, syncing, daemon-down, or error.

Eleven commands are contributed, all prefixed Codegraph: in the palette — sign in, sign out, reconnect, change organization, department, project or connector, refresh, retry, sync now, and show daemon status.

Supervision

The extension starts and supervises the daemon itself: on sign-in, on every editor restart, and whenever it finds the daemon unreachable after a crash or a reboot. You never run fabric-sync daemon by hand.

It needs the fabric-sync binary resolvable on PATH or named in the fabricSync.binaryPath setting. Eight settings are available in total, including fabricSync.gatewayUrl for a self-hosted deployment and fabricSync.autoConnect.

Terminal agents alongside the extension

A session opened against the Wexa MCP server does not by itself start sync. Once a repository is registered through the extension, hooks for terminal agents can be installed separately:

fabric-sync supervise --repo . --json --install-agents
fabric-sync connect --repo .

That installs a fabric-sync shim on PATH, the four git hooks, and hooks for the terminal agents it knows about. Any local agent that writes a file then wakes the same daemon, so one daemon serves the editor and the terminal at once.

Related