Configuration

Use this when choosing runtime defaults or documenting CLI/env knobs for fleet usage.

Recommended Defaults

Settings / Knobs

Runtime Clamps / Fallbacks

Panther/setup logs are administrator troubleshooting evidence only. They do not decide compliance or override the signed public policy verdict.

On-Disk State

By default the client runtime keeps its policy cache as one compact, atomically written record in the operating-system temp directory, not as a permanent file under %LOCALAPPDATA%. On-disk state is an optimisation only: it never changes the signed compliance verdict and never changes the exit code. A verified remote policy is always used even when the state write is skipped or fails.

The record is a fixed 50-byte little-endian header followed by one zlib-deflated body of the signed policy bytes and the detached signature:

off  size  field           value / meaning
  0     8  magic           DB A7 0D 0A 53 54 52 31        (STATE_MAGIC)
  8     2  format_version  uint16, must equal 1
 10     4  policy_len      uint32, exact length of the signed policy bytes, uncompressed
 14     4  signature_len   uint32, exact length of the detached signature, 0 when absent
 18    32  body_digest     sha256(policy_bytes + signature_bytes) over the uncompressed body
 50  rest  body            zlib.compress(policy_bytes + signature_bytes, 9)

The tool reads a record only at a path it derived itself and removes one only after confirming its first eight bytes match STATE_MAGIC and it did not yield a signature-verified policy, so a foreign file at the same path is never deleted. An unusable record self-heals on the next run. The record format is compact because it stores two exact byte blobs and a digest. It is not a confidentiality mechanism and provides no protection against inspection of any kind.

--stateless applies to the compliance run: that run reads and writes no state. --purge-state and --show-state deliberately ignore it and act on the real location, so a fleet that normally runs stateless can still inspect and clear what an earlier stateful run left behind. In the --show-state payload the stateless field therefore reports the configured setting while layout and source describe the inspected location.

--diagnose-config reports cache_file as the effective runtime location: a configured --cache-file when one is set, otherwise the state record path, and null when the run is stateless. state_layout, state_path, state_dir, state_dir_source, stateless, stateless_source, cache_file_source, and state_format_version report the rest of the resolved scope and where each value came from.

--cache-file (and WIN11_RELEASE_GUARD_CACHE_FILE) selects the legacy JSON cache pair instead: the write primitive never creates directories, so a --cache-file under a missing parent directory is skipped with a cache_write_failed source problem rather than creating a tree. The pair holds the publisher's exact signed policy bytes beside the detached signature, as it always has, so its line endings are whatever the feed publishes and the tool imposes none of its own.

cache.py keeps a separate save_policy_cache / save_cached_policy pair for embedders that the client runtime never calls. Those helpers now serialise their JSON and hand the bytes to the same write primitive, so the file they write uses LF line endings on every platform instead of the platform's own convention, and they return without raising when the destination cannot be written.

Deprecated / Avoid

Verify

python -m win11_release_guard --diagnose-config
python -m win11_release_guard --show-state
pytest -q tests/test_cache.py tests/test_cli.py tests/test_state_cli.py

Related Pages

Home | CLI and RMM Usage | Policy Feed and Trust Model