hermes approvals test --env-type docker --json -- reboot exited 0. The verdict was allow. The rule field was empty. The detail said an isolated container backend skips all command guards except approvals.deny.

The same words with the env type left at local exited 3. The verdict was hardline-deny. The rule was system shutdown/reboot. The detail said the hardline blocklist is never bypassable, including under --yolo and approvals.mode: off.

Those two details are both printed by the same handler. They are not two views of one floor. The local line is the floor. The docker line is a backend shortcut that the dry-run always takes for docker and modal. The shortcut does not ask whether that backend has a host path mounted. The runtime does.

grok inspect --json in the main checkout left the permission source list empty. The same command in a linked worktree named that checkout’s .claude/settings.local.json and reported loaded as 2. The worktree did not contain the file. The main checkout was projectTrusted: false. The worktree was projectTrusted: true.

Those two lines are not a view of one trust bit. The file the main inspect skipped is the file the worktree inspect counted. If you set GROK_WORKTREE_INHERITS_MAIN_APPROVALS=false and then read only the flag, you will miss the source that stayed.

The remediation says to check the proxy, the VPN, the firewall, DNS, a custom CA, and WebSocket policy. On Codex CLI 0.163.0 the handshake under that sentence is a 401, and the message in the 401 is Missing bearer or basic authentication in header. DNS had already returned addresses. The HTTP reachability row was ok. Proxy environment variables were none. Auth mode was none.

Those two lines are not the same failure. The summary points at the path. The detail points at the header. Codex CLI 0.166.0, installed beside the older binary and not put on PATH, prints the same remediation and still records auth mode none. It redacts the 401 body. The flag added in that release, codex doctor --network-only, then drops the auth row and exits 0.

grok memory clear --yes printed one sentence and exited 0. The sentence was Nothing to clear: no memory files found. Standard error was empty. The global topic file was still under memory-v2/global/topics/. A note under memory-v2/workspaces/ was still there. The older memory/MEMORY.md was still there.

The exit code is not an inventory. On this binary the default clear can report an empty store while the files a later session is told to read are still on disk. --all can then print Memory cleared. after deleting only the global directory.

The trust entry was <subdir>. The session opened <repo>. <repo> was not on the list, so delta never loaded. hermes skills trust <subdir> had already exited 0 and printed that one project skill would load in sessions started inside this repo.

That sentence is the wrong object. On this binary the path you pass is the path that is stored. The path a later session opens is the nearest ancestor that contains .git, and only when that ancestor is an exact entry in skills.trusted_project_dirs. A folder inside a checkout can be trusted, counted, and still be invisible to every session that starts in it.

The allow array went from 17 rules to 1. claude auto-mode config exited 0. Standard error was empty. The only remaining allow rule was the one-line probe. Scheduled-Task Fires was gone. Git Push Destination was gone. Nothing in the command output said that 16 built-in exceptions had been discarded.

That is the check. An autoMode.allow list that forgets the literal "$defaults" does not add a sentence to the classifier’s exceptions. On the two binaries measured here, it replaces the printed allow list. The configure-auto-mode page, read on 31 October 2026, says the same thing. The October 31 changelog sentence about scheduled-task prompts does not show up as a kept label in the print.

The operator note and the constructor do not describe the same cron session. In this install, cron/AGENTS.md says cron sessions pass skip_memory=True, and that memory providers intentionally do not run during cron. The function that builds the agent, _construct_cron_agent in cron/scheduler.py, passes skip_memory=False. A comment in agent/agent_init.py agrees with the constructor, not with the note: cron agents now take the normal memory path.

That disagreement decides whether a scheduled agent job can sit forever inside a file lock. The note is what a reader of the install tree is likely to trust. The call is what the process runs. On this binary they are not the same sentence.

restart came back with a printed probability of 1.0. The conformal set still contained restart, wait, and escalate. session.adopt() then raised ValueError: Candidate did not pass its adoption checks, and session.predict() raised ValueError: Assess and adopt a skill before predicting. The candidate file was on disk. It was not a skill the session would serve.

That is the check. A System 1 teaching session can print a near-certain label and still withhold every row. If you restart a process because the raw guess looked sure, you skipped the gate the 1.2.0 session actually enforces.

cat secret.env under codex sandbox --permission-profile env-deny exited 1. The error was Permission denied. A write in the same repository under :read-only failed with a different sentence: Read-only file system. Those are not two wordings of one policy. One is a path rule. The other is a read-only mount. A domain allowlist has a third failure, and a raw socket does not produce it.

On Codex CLI 0.163.0, a profile with network.enabled = true and the network proxy feature left off opened a direct TCP connection to example.com port 80. The first bytes back were HTTP/1.1. The same binary, with features.network_proxy = true and an allow entry only for example.com, refused http://info.cern.ch/ through the proxy client. The body was JSON, and the message was Domain not in allowlist. A Python socket connect in that second configuration never reached the allowlist check. Name lookup failed, and a connect to the address resolved outside the sandbox was Network is unreachable.

The success line was specific. After hermes profile create labclone --no-alias --clone-from labsource, Hermes printed that it had cloned config, .env, SOUL.md, and skills from labsource. It did not mention memory. memories/MEMORY.md and memories/USER.md were on the clone anyway, and their SHA-256 hashes matched the source byte for byte.

That gap is the check worth running before a second always-on agent is pointed at the new profile. The files that moved are the agent’s identity. The sentence that reported the copy is not the inventory.