CODEAF_HOME does not hold furrow's snapshot store, so two profiles share one under ~/Library #1769

What happened

2026-10-05, dev@f81638787 (dev-20261005-f816387875e5), macOS. Found in the v0.7.1 happy-path pass.

codeaf help env describes CODEAF_HOME as "the whole state root". With CODEAF_HOME=/tmp/a and HOME=/tmp/b, an ordinary codeaf chat session still writes under HOME:

/tmp/b/Library/Application Support/dev.furrow.furrow/store-v1/{catalog.sqlite3,locks,packs,workspaces}
/tmp/b/Library/LaunchAgents/ai.agentfield.codeaf.tick.plist.lock

So two homes that set different CODEAF_HOME but share a HOME share one furrow snapshot store. That covers test drives, make demo-home, and a person keeping a second profile. Test runs on a developer's machine therefore write into the developer's own store. scripts/hosted-drive.sh says "It never writes to your own home folder's state", and this store is the exception.

Replication

Deterministic (no model). On macOS, run HOME=$(mktemp -d) CODEAF_HOME=$(mktemp -d) codeaf chat --once "hi", which needs a key; any launch that opens a conversation shows the same. Then list $HOME/Library.

Where

How codeaf launches or configures the bundled furrow (internal/furrow, internal/furrowbin). The store path is chosen by furrow's own default, not handed down from CODEAF_HOME. Also the tick lock path in internal/standing/watch.go.

The fix

The furrow store lives under CODEAF_HOME, or is passed to furrow from it, so one CODEAF_HOME is one complete, separable profile. The LaunchAgent belongs to the OS and can stay where it is, but its lock does not need to. If the store must stay shared on purpose, help env says so.

Acceptance

• e2e: a session with CODEAF_HOME and HOME both set to temporary folders leaves nothing under $HOME/Library/Application Support.