[GH-ISSUE #192] fix(application): avoid requiring snapshot write permission for direct analysis cache hits #137

New issue

Closed

opened 2026-10-15 18:21:31 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:21:31 +00:00

Owner

Originally created by @morluto on GitHub (Jul 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/192

Problem

runDirectAnalysis requests both snapshot_read and snapshot_write authorization whenever snapshotPath is provided, even when the command can be fully satisfied from an existing snapshot cache.

In authorizeAnalysis() (src/application/DirectAnalysis.ts), snapshot capabilities are added unconditionally before checking whether the requested query is replayable:

It always requests snapshot_read and snapshot_write for snapshotPath with write access.
prepareSnapshot() may return cached evidence and runAnalysis() returns it without opening Hopper or modifying the snapshot.

This blocks read-only snapshot use-cases: a policy that permits cache reads but not snapshot writes cannot execute cached replay even though no write would occur.

Repro steps

Create a valid snapshot for a binary with at least one query result.
Run a direct tool command (for example rea analyze) with --snapshot against that cache while permission policy includes snapshot_read for the file but no snapshot_write.
Observe permission preflight failure on snapshot_write even when cached evidence exists.

Expected

If prepareSnapshot() has a replayable hit, authorization should only require snapshot_read (unless the operation actually needs to persist new evidence).

Observed

Permission preflight always requests snapshot_write, forcing operators to grant a broader path authority than needed for replay.

Impact

Unnecessary permission scope expansion for CLI and MCP callers.
Prevents strict read-only snapshot workflows from using local replay.

Scope

src/application/DirectAnalysis.ts only.

Notes

This is separate from broader permission model work (e.g. #114); this is a concrete over-authorization in the current snapshot cache fast path.

Originally created by @morluto on GitHub (Jul 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/192 ### Problem `runDirectAnalysis` requests both `snapshot_read` and `snapshot_write` authorization whenever `snapshotPath` is provided, even when the command can be fully satisfied from an existing snapshot cache. In `authorizeAnalysis()` (`src/application/DirectAnalysis.ts`), snapshot capabilities are added unconditionally before checking whether the requested query is replayable: - It always requests `snapshot_read` and `snapshot_write` for `snapshotPath` with `write` access. - `prepareSnapshot()` may return cached `evidence` and `runAnalysis()` returns it without opening Hopper or modifying the snapshot. This blocks read-only snapshot use-cases: a policy that permits cache reads but not snapshot writes cannot execute cached replay even though no write would occur. ### Repro steps 1. Create a valid snapshot for a binary with at least one query result. 2. Run a direct tool command (for example `rea analyze`) with `--snapshot` against that cache while permission policy includes `snapshot_read` for the file but no `snapshot_write`. 3. Observe permission preflight failure on `snapshot_write` even when cached evidence exists. ### Expected - If `prepareSnapshot()` has a replayable hit, authorization should only require `snapshot_read` (unless the operation actually needs to persist new evidence). ### Observed - Permission preflight always requests `snapshot_write`, forcing operators to grant a broader path authority than needed for replay. ### Impact - Unnecessary permission scope expansion for CLI and MCP callers. - Prevents strict read-only snapshot workflows from using local replay. ### Scope - `src/application/DirectAnalysis.ts` only. ### Notes This is separate from broader permission model work (e.g. #114); this is a concrete over-authorization in the current snapshot cache fast path.

bsakaguchi

2026-10-15 18:21:31 +00:00