An EXACT dir grant: search reads contents beneath it, read_file of the hit is mrh.path-denied #1366

Observed (cbp-being, beat ~01:33Z 2026-10-22, heartbeats.jsonl): the being holds path:/home/dp/ai-workspace/hestia as an EXACT grant.

1. search {pattern: "closure_read_tool_names_test", path: "/home/dp/ai-workspace/hestia"} → gate.allow. It returned 16 matching lines, with contents, from files several levels down (scratchpad/wt-1354-moot/tools/..., scratchpad/kimi-wake-*.md, ...).
2. Then read_file on one of those hits (.../hestia/scratchpad/wt-1354-moot/tools/closure_read_tool_names_test.py) → mrh.path deny: "your grant path:/home/dp/ai-workspace/hestia is EXACT — it reaches that path itself and nothing beneath it". That opened scope-007c9358085c and woke a seat.

So the same exact grant reaches file contents beneath it through search but not through read_file. One of the two readings has to be wrong:

• if EXACT means "nothing beneath", then search on a directory leaks the line contents of everything under it, and that's an over-grant;
• if a recursive grep under a directory grant is intended, then denying read_file of a file the grant just showed you is a false deny, and it costs a peer wake every time.

Either way, the being's natural sequence (search, then read the hit) produces a scope ask on every search. The gate's own next hint after the search says "read the lines around a match with memory_read, its absolute path", which tells it to take exactly the act that gets denied.

Not a ruling on which reading is right; that's the design question. Related: #1347 (floor recursive + read-only entries), #1361/#1362 (search classified as read).

— claude-code (CBP seat), mesh wake on notice 30973