The marketplace entry said 4.5.6. The root plugin.json said 1.2.3. The file under .codex-plugin/ said 9.9.9. codex plugin add reported 9.9.9. It would not have reported any of those strings if the third file had been absent. On that package the same command exited 1, printed missing plugin.json, and did not name the path it had failed to open.

codex plugin list had already printed the source directory. The only manifest in that directory was plugin.json at the plugin root. The file add required was .codex-plugin/plugin.json. Those are not two prints of one file. List can resolve a portable package, and add can still refuse it, before any version comparison runs.

A later --option with the same key used to replace the description a System 1 model would see. The command still looked like two choices. Only the last text was kept, and the process did not say a description had been dropped. On the system1-agents checkout tested here, that replacement does not happen. s1a decide exits 2, names the repeated key, and prints neither description.

That exit is the request gate. It is not a score, and it is not a calibration result. A request that gets past it still has to find a key. A request that names a key still leaves the machine. The useful split is which of those failures you are looking at, because they do not mean the same thing and they do not happen in the same place.

hermes hooks doctor printed hook will NOT fire at runtime. In that same process HERMES_ACCEPT_HOOKS was 1. The registration call then wired the hook and wrote the allowlist pair the doctor line had just called missing.

That sentence is the allowlist file. It is not the runtime decision. On Hermes 0.22.5 the runtime also accepts hooks_auto_accept: true and --accept-hooks. Doctor does not read any of the three. A second doctor run, after the write, said the same hook was healthy.

The plugin object said provides.skills was 2. The loaded skill list had one name, inside-skill. The missing directory was a symlink. Its target was an ordinary skill directory, the SKILL.md there was readable, and Grok 1.0.67 did not print a skip.

That pair of numbers is not the install result. grok plugin install --trust on a plugin whose only skill was the same kind of outside link exited 0 and said it installed the plugin. The installed copy had an empty skills directory. A later grok inspect --json of that home reported provides.skills as 0 and an empty skill list. grok plugin details on the same installed copy still said 1 skill dir(s).

The install error named <parent>/plugins/probe-plugin. The file just added was <market>/catalog.json. The plugin directory was <market>/plugins/probe-plugin, beside the catalog, not beside the parent. claude plugin validate on that file had exited 0. Its warning had already named plugins[0] plugin.json under <market>.

Those two directories are not two prints of one root. Validate read the plugin from the directory that holds the catalog. claude plugin marketplace add exited 0 and stored the parent as installLocation. Install then looked there. The plugin was never in that parent.

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.