What's wrong with this entry?
The --apply-file flag now requires a preceding --expect-sha256 <64-hex> argument. The apply step is refused unless the proposal file's exact bytes hash to the given SHA-256, preventing a file-swap attack between review and apply.
# Step 1: generate proposal (unchanged)
/auto-mode-setup --wizard posture=personal scope=all depth=both --propose
# Step 2: apply with hash
/auto-mode-setup --expect-sha256 <64-hex> --apply-file /tmp/auto-mode-proposal.json--expect-sha256must come directly before--apply-fileand must not use=syntax- Optional
--request-id <uuid>can be placed first; the UUID is echoed back in the JSON result asrequestId, letting a host correlate replies to requests --request-idmust be in canonical 8-4-4-4-12 hex-and-dash UUID format- Passing
--request-idafter--apply-fileis an error; it must come first - The hash mismatch error is: "The proposal file's bytes do not match the reviewed digest"
New argument parser (search for "--expect-sha256 is required" or "--request-id must be a UUID").
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.