Code sync

Code sync keeps the code graph in step with a connected repository. It is how a codebase stops being a folder an agent has to be handed one file at a time and becomes context a question can be asked of.

The code graph

The code graph is the representation of a repository's code — its files, its symbols, and the calls between them. It lives alongside the rest of a project's context graph, under the same project isolation and the same governance.

Two tools read it, and both are available in every deployment regardless of which services are configured:

• search-code finds code by text, symbol or identifier, and returns the matching lines with their file paths.
• fetch-code reads a span of a file, or one symbol, once you know where to look.

The intended sequence is search and then fetch: locate first, read second, so an agent spends its context on the few spans that matter rather than on whole files. Structural questions — what calls this, what does this import — are traversals, and query-context answers those against the same graph.

A repository connection is not a connector

This distinction is the most common confusion on this page, and there are four concrete differences rather than a matter of emphasis.

It cannot be provisioned. A repository is not in the set of connectors provision-connector can provision, so the verb that brings connectors into being does not apply here at all. See connectors.

It is established by the client. The code-sync client registers the checkout itself, over the code-sync surface, as part of signing in. There is no separate provisioning step to perform first.

It mints no skills. Provisioning a connector creates one skill per action it supports, which is the whole reason provisioning exists. A repository connection creates none — there are no actions on a repository for an agent to call.

Its output is a graph, not a capability. What a connector gives an agent is a set of things it can do. What a repository connection gives an agent is a body of code it can read.

The two paths overlap only in that both end with something queryable in the project. They are reached differently, governed by different grants, and named differently on purpose.

The daemon and the editor extension

Three pieces cooperate, and they are easy to confuse because they are usually installed together.

The daemon does the work. fabric-sync runs locally, watches the git working tree, and pushes what changed to the gateway. It is the only piece that touches your code, and it keeps the code graph in step incrementally rather than re-reading the repository each time.

The editor extension drives it. The VS Code extension — it ships as Codegraph — is where you sign in, and where you see whether sync is running, what it has done and whether anything failed. It activates when it finds a git working tree or an existing sync configuration in the workspace, and it writes the configuration file the daemon and the other clients then read. It does not do the syncing; it starts and supervises the daemon that does.

The launcher connects the two to an assistant. fabric-connect registers the checkout, starts or reuses the same daemon, queues a catch-up pass, and then proxies a stdio connection to the gateway for an assistant such as an editor agent or a desktop client.

How a repository becomes queryable

The flow is the same one the Wexa MCP server's clients use, which is why an editor can do it without a separate credential.

1. Sign in. A browser authorization grants the client a token scoped to one organization, department and project. That scope is what decides where the code lands.
2. Register the checkout. The client ensures the project's repository connection exists and picks up the addresses it needs, and a launcher running on a cloud machine can get a short-lived token for the same purpose rather than storing a long-lived one.
3. Catch up. The first pass is a bulk ingestion of the existing tree. Because it can take a while on a large repository, it is submitted as a job: the response carries a job identifier and a separate call reports that job's status. See ingestion.
4. Keep up. After that the daemon sends incremental events as you work, so the graph tracks the working tree rather than the last full pass.

For a repository nobody watches locally — a shared service, a repository nobody has checked out — the gateway can accept push and pull-request events from the host instead, so the code graph tracks the remote rather than someone's laptop.

Where the code lands is not the client's decision

Every code-sync request is pinned to the scope of the token that made it. The organization and project on the payload are overwritten from the token before the request is forwarded, so a client cannot ingest into a project it was not granted no matter what it sends. That check happens at the edge, where the caller is, rather than only deeper in — see scope and server-bound arguments.

What this is not

It is not the knowledge base. Source code in the code graph is structure — files, symbols, calls — and it is found by searching text and traversing relationships, not by similarity to a question. Design documents about the code are prose, and those do belong in the knowledge base.

It is not the data catalog either. The catalog describes data assets that live outside Wexa; the code graph holds a representation of the code itself.