settings.system.json: 'cd && <trusted tool>' is declared safe in autoMode.allow but has no deterministic permissions.allow rule

[xmasyx]

Summary

LifeOS/install/settings.system.json declares that compound cd && <trusted tool> commands are safe, but that intent lives only in autoMode.allow (a natural-language list evaluated by a classifier). The deterministic permissions.allow list has no rule matching cd, so these commands fall through to a judgment call instead of a hard allow.

Result: intermittent permission prompts for commands the config itself calls safe.

Evidence (read from the repo at main)

LifeOS/install/settings.system.json, autoMode.allow:

"Compound commands chaining trusted tools (cd && bunx, cd && bun, cd && git, cd && wrangler) are safe — cd just changes directory before running an allowed command",

Same file, permissions.allow — 229 entries, 132 of them Bash(...):

• Bash(bun:*), Bash(bunx:*), Bash(bun run:*) are present
• zero entries begin with Bash(cd

Claude Code's deterministic matcher evaluates each segment of a compound command. In cd <dir> && bun <script>.ts the bun segment matches an allow rule; the cd segment matches nothing. With defaultMode: "auto" the decision then falls to the autoMode classifier, which is inherently non-deterministic — matching the reported symptom of prompts appearing sometimes rather than always for an identical command shape.

Impact

Any install using the shipped settings.system.json in auto mode gets sporadic prompts on the most common command shape in the system (cd <workdir> && bun <tool>.ts). Because the prompt renders the whole command, users read it as a prompt on bun, which is already fully allowed — so the cause is easy to misattribute.

Proposed fix

Add one entry to permissions.allow in LifeOS/install/settings.system.json:

"Bash(cd:*)",

This is low-risk: allowing cd does not allow the chained segment. Each segment is still matched independently, so cd X && rm -rf Y remains subject to the rm -rf rules, and permissions.deny still takes precedence over everything.

Alternative

If blanket-allowing cd is not desired, the opposite fix is equally valid: remove the autoMode.allow line above, so the config stops declaring an intent it does not enforce deterministically.

Either way the two layers should agree.

Note

The same file also appears at LifeOS/install/skills/LifeOS/install/settings.system.json, which looks like an unintended nested duplicate from packaging. Worth checking separately.

[xmasyx]

Follow-up: I measured what the missing deterministic rule actually costs, and the number is bigger than "an occasional prompt".

Method. Wall-clock between tool dispatch and tool result, one command at a time. Commands issued in a parallel batch are queue-confounded and unusable for this, so every figure below is from a solo run.

Results.

Command	Latency
bun --version (matches Bash(bun:*))	0.05 s
cd <dir> && bun --version (with Bash(cd:*) added)	0.04 s
python3 --version (with Bash(python3:*) added)	0.05 s
a command with no matching prefix rule	1.7 - 2.1 s
same trivial command, repeated	up to 27 s

Two clean bands: ~0.05 s when a deterministic rule matches, and seconds when nothing matches and the decision falls through to the classifier. No human approval was involved in any of these runs (confirmed with the operator) — the 2-27 s spread is the judgment layer's own latency on the same trivial command.

Why this strengthens the report. The declared-but-not-executive intent in autoMode.allow doesn't merely prompt intermittently; it puts a model call in front of every invocation of the most common command shape the system emits (cd <dir> && <trusted tool>). Adding the deterministic rule removes that call entirely, and the effect is measurable at 35x on the tools that got one.

One caveat worth folding into the fix. A prefix rule cannot cover inline-code flags. With Bash(python3:*) present, python3 --version dropped to the deterministic band, but python3 -c "<code>" never did (2.1 s for a trivial body, 27 s on a repeat). So any autoMode.allow phrase that blesses a tool invoked with inline code (-c, -e) cannot be made executive by a prefix rule; the rule only helps the non-inline forms. Worth stating explicitly wherever the allow list is documented, otherwise the rule looks like it covers a case it structurally cannot.

Caveats on the numbers: single install, single run per figure, not a benchmark. The bands are far enough apart that the direction is not in question, but the exact values are not.