Four documentation claims the code does not honour

[lfnothias]

Grouped because they share a cause — the docs describe an intent the code does not implement — and because a wrong SECURITY.md is worse than no SECURITY.md.

1. "The seed never appears in argv or the environment" (SECURITY.md:29, README.md:162, lib/totp.sh:3) — false on the keychain store path. Fixed in Audit fixes: a dead backend, a false completion, and the seed in argv #1; the wording should also gain a note that -T /usr/bin/security lets any same-UID process read the seed back without a prompt, since the docs present keychain as the strong backend.

2. "Verifies we can authenticate before bringing up a full-tunnel VPN" (docs/vpn-hooks.md:15, comment at lib/session.sh:144) — the code only checks that a seed string is retrievable. It never attempts authentication. The stated rationale (don't strand other remote access behind a tunnel you can't use) is good; the check does not deliver it.

3. "config precedence" listed among what the tests cover (README.md:178) — hs_load_profile, the function that implements precedence and the only thing that sources a user profile, is never called by tests/run_tests.sh.

4. local helps sshfs (lib/session.sh:176 and the docs) — hs_local exports RSYNC_RSH and GIT_SSH_COMMAND. sshfs honours neither; it takes its transport from -o ssh_command=. So hpc-session local sshfs ... opens a brand-new, unmultiplexed connection — which under TOTP means a second authentication, the exact thing this tool exists to avoid.

Each is a one-line doc fix or a small code fix; (2) and (4) are worth deciding which way to resolve rather than just editing the prose.

From an adversarially-verified audit, 2026-07-30.