warehouse: --dir makes a populated DuckDB store read as empty, and a missing store is silently created

[anandgupta42]

What happens

Passing --dir <path> makes a populated DuckDB store read as empty, with no error. Four arms, same compiled binary, same store file, same cwd:

Arm	Invocation	Result
A	no --dir	Contract, Lead, Opportunity
B	--dir only	no tables
C	OPENCODE_PURE=1 only	Contract, Lead, Opportunity
D	--dir + OPENCODE_PURE=1	no tables

--dir is the trigger. A direct Node probe reads the same file as Contract, Lead, Opportunity, OpportunityLineItem, Quote.

Why this is worse than a crash

The failure surfaces as "no tables", not an error. An agent handed an empty result set has no fault signal to key on — it answers confidently from nothing. A benchmark sweep in this state completes and reports a fully-traced, plausible score computed off empty databases.

Mechanism

Two independent defects compose:

1. Relative store paths follow the working directory. --dir calls process.chdir(args.dir) (packages/opencode/src/cli/cmd/run.ts:412). ConnectionRegistry.load() never absolutizes the path field, so a relative path in ~/.altimate-code/connections.json resolves against whatever cwd the process happens to have when the driver opens it.

2. Opening a warehouse connection silently creates the store. packages/drivers/src/duckdb.ts calls new duckdb.Database(dbPath, …), which creates an empty database on a miss. packages/drivers/src/sqlite.ts passes create: !isReadonly to bun:sqlite, which does the same. Neither checks that the file exists.

So the mis-resolved path lands on nothing, an empty database is conjured there, and every subsequent query succeeds and returns zero rows.

Defect 2 is the root hazard and is independent of --dir — any path mistake produces the same silent-empty outcome.

Reproduced

Against a compiled binary built with the production build options, run from an unrelated working directory with --dir:

{"ok":true,"cwd":"…/project","tables":[]}

and three stray files left behind at the --dir target:

…/project/warehouse.db      4096 bytes
…/project/warehouse.db-wal
…/project/warehouse.db-shm  32768 bytes

The DuckDB arm leaves a 12,288-byte stray .duckdb file, matching the stray 12 KB file an earlier investigation found in the wrong directory.

Expected

• A relative store path resolves against a stable, documented base, not the working directory.
• Opening a warehouse connection on a missing file fails loudly. Creation is explicit and opt-in.

Not covered by existing work

Checked against #1122, #1192, #1198, #1201 (driver resolution, load, concurrency). None of them touches path resolution or create-on-open.