> Source: https://wexa.ai/docs/surfaces/tools-and-extensions/launcher-and-editor-extension # 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. | | Wexa Connect | Codegraph | |---|---|---| | What it is | A command-line launcher | An editor extension | | For | Agent clients driven from a terminal | VS Code, Cursor, Windsurf and other forks | | Starts the daemon | Yes, on every session | Yes, and supervises it across restarts | | Also does | Opens a session against the Wexa MCP server | Sign-in, project and connector selection, live status | | Version | `@wexa/fabric-connect` 0.1.0 | 0.4.2, publisher `WexaAI` | 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`](/docs/tools/search-code) and [`fetch-code`](/docs/tools/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. ```bash cd tools/fabric-connect npm install && npm run build npm link # puts `fabric-connect` on PATH ``` Point a client's server configuration at it: ```json { "mcpServers": { "fabric": { "command": "fabric-connect", "args": [], "env": { "FABRIC_GATEWAY_URL": "https://fabric.wexa.ai", "FABRIC_SYNC_TOKEN": "" } } } } ``` 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 ```bash 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: ```bash 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: ```bash 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 What the code graph holds and how it stays current. The tool that reads what these two keep synchronised. Loading one span of a file by path and line range. What a connector is, and why a repository connection is not one.