From your save to your agent's answer
The short answer
You save a file. A daemon already watching your working tree sees the write, re-parses that one file, replaces the nodes it had produced and re-points the edges into them. The panel returns to synced, and the next question your agent asks returns the code you just wrote. Nothing about how you work changes, and no step in that chain waits for a scheduled scan.
- 01
You save a file
Nothing about your workflow changes. You edit in your editor and press save, the way you did before CodeMesh was installed.
- 02
The daemon notices
- 03
That one file is re-parsed
- 04
The graph is updated in place
- 05
The panel says it landed
- 06
Your agent asks, and gets the new answer
Why it is a daemon and not a build step
An index that refreshes on a schedule is wrong for exactly as long as the gap between refreshes, and the gap always lands on the file you are working in. A watcher on the working tree has the opposite property: the only moment the graph disagrees with your editor is the fraction of a second between the write and the re-parse.
It also decides what gets read. A build step is handed a commit, so it sees committed work and nothing else. The daemon is watching the tree you are actually editing, which is why uncommitted changes and staged work are visible to your agent, and why the data policy says so in as many words.
What re-parsing one file means
Functions, classes and imports are extracted with their line spans, so the graph knows not just that a symbol exists but where to find it. When the file changes, the nodes that came from it are replaced and the edges pointing at them are re-pointed. The rest of the graph is untouched, which is why a save costs the same whether the repository has a thousand files or a hundred thousand.
The panel is where you watch this happen. It is the same view on the right, running.
What your agent sees
The point of all of it is the exchange below: a question, one structural call, the spans that answer it, and an answer. No repository crawl, and no reading of files that turn out to be irrelevant.
- you
Where does the transport give up retrying, and what happens to the job when it does?
- codemesh
code-contextretry budget and exhaustion - src/transport/retry.ts:34
const MAX_ATTEMPTS = 5; - src/transport/retry.ts:72
if (attempt >= MAX_ATTEMPTS) return dead(job); - src/queue/dead.ts:19
export function dead(job: Job) - agent
retry.ts stops at MAX_ATTEMPTS, which is 5, and hands the job to dead() in src/queue/dead.ts. That moves it to the dead-letter queue rather than dropping it, so it stays inspectable.
Does the daemon slow my machine down?
What happens while I am offline?
Do I have to commit for my agent to see a change?
Can I see what my agent asked for?
Install it and watch your own repository sync
The panel above is the real client. Installing takes a file and a sign-in.