A fold marker attributes content to a command that never emitted it, including a bare cd

[fajarhide]

omni 0.7.9, macOS, Claude Code.

A fold marker's from clause names a command that cannot have emitted the folded
content. One of them is a bare cd.

Repro

In any repo with a file of about 45 lines, after a session has run a few commands:

cat -n src/db/index.ts

Real output on my machine, verbatim except that an absolute home path is shortened:

[OMNI: 5 lines already shown from cd ~/project/<repo>, omni retrieve 45969982e062c2b2]
     6
[OMNI: 14 lines already shown from cd ~/project/<repo>, omni retrieve 6d87e802f2423855]
    21    return new Kysely<Schema>({ dialect: await dialectFor(url) });
    22  }
    23
    24  let opened: Promise<Kysely<Schema>> | undefined;
    25
[OMNI: 18 lines not shown here from for f in app/api/agents/\[id\]/run/route, omni retrieve 4db090958edbdb3f]
    44
    45  export type { Schema } from "./schema";

Lines 26 to 43 are a database() function in src/db/index.ts. They are attributed to
for f in app/api/agents/[id]/run/route. That path is a Next route handler and I
confirmed with grep that src/db/index.ts contains no reference to it, and that the
route file does not contain the folded lines.

The first two blocks are attributed to cd ~/project/<repo>. A cd emits nothing, so it
cannot be where those lines were already shown.

The content is recoverable: all three handles retrieve correctly.

Why it matters more than wording

A subagent doing an authentication change in this repo hit this and reported that the
Read tool had returned content belonging to another file. It had not. Read was
correct every time; the shell output was folded and the marker pointed at a route file, so
the agent concluded its file reads were untrustworthy and re-read everything with cat
and sed before relying on it. The wrong from did not cost correctness here, but it
cost a full pass of re-reading and produced a false report about a different tool.

A reader who chases the named command finds nothing, because the named command never
produced those bytes.

Where it probably lives

#736 found Ledger::from is passed on one of three doors, leaving the #622 differing
source check inert in process_payload and pipe::distill. This looks like the residual
of that on the Bash door: a from is printed, and it is whatever the ledger happened to
hold rather than the command that emitted the block.

Different from #767, which is about a marker stating what the ledger did instead of what
the reader stopped for. Here the marker states a fact, and the fact is wrong.

Suggested fix

If the source of a folded block cannot be established, print no from clause at all
rather than the last command in scope. A marker with no attribution is honest. A marker
naming an unrelated file is a false lead.

A command that produced no stdout should never be eligible as a from.

[fajarhide]

Triaged priority: high, stage: now, and left for a session with time to trace it
properly rather than started at the end of one.

A hypothesis to test first, not a diagnosis. cd ~/project/<repo> is almost certainly
the first line of a multi-line command, and #750 taught this repository that agents write
commands that way constantly. The ledger records a source per sighting, and #752 changed
how a command is split into segments. So the shape to check before anything else is
whether the recorded source is the first segment of a multi-line command rather than the
command that produced the lines.

If that is what it is, it arrived with my own change on 2026-09-04 and the fix belongs
next to it. I am not claiming that; the repository's own rule is that a mechanism named in
a report is a hypothesis, and this one is mine rather than the reporter's.

Where to start. ledger_record is given self.source (ledger/mod.rs), which is
whatever .from() was handed, and the hook hands it normalized.command whole. Compare
that against what differing reads back, and check whether a bare cd can ever be the
value stored for a line a later command printed.

Not the same as #767. That one is about what a marker says; this is about the marker
naming the wrong command, which is the false-claim class rather than the wording class.