> Source: https://wexa.ai/docs/concepts/code-sync

# 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](/docs/concepts/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`](/docs/tools/search-code) finds code by text, symbol or identifier, and returns the
  matching lines with their file paths.
- [`fetch-code`](/docs/tools/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`](/docs/tools/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`](/docs/tools/provision-connector) can provision, so the verb that brings
connectors into being does not apply here at all. See [connectors](/docs/concepts/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](/docs/concepts/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](/docs/get-started/scope-and-server-bound-arguments).

## What this is not

It is not the [knowledge base](/docs/concepts/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](/docs/concepts/data-catalog) either. The catalog describes data assets
that live outside Wexa; the code graph holds a representation of the code itself.