hermes resume exited 0. The sentence was Hermes is not paused, and it named the sentinel path. The next hermes status still printed the pause banner, with no reason on it. The path in the resume sentence was a directory. The directory was still there after the command returned.

That is the line that will mislead a wrapper. On this install, a directory named ESTOP holds the stop. Resume reports that the stop is gone because it cannot unlink a directory. Status keeps reading the directory as engaged. A script that treats the resume sentence as the state of the pause will start work that the scheduler is still skipping.

The skill file was already on disk. skills/greet/SKILL.md held a name, a description, and one sentence of instructions. .codex-plugin/plugin.json named the plugin demo-plugin, set version 0.1.0, and set a description. muse plugins validate still exited 1. The diagnostic code was invalid-manifest-schema. The message was one sentence:

this Codex plugin declares no importable skills yet (hooks/MCP/commands are not imported in this phase)

That sentence also printed when the tree had no skills/ directory, and when the manifest pointed at hooks/hooks.json instead of a skill. A script that treats it as “the skill file is missing” will look in the wrong place. On this binary the sentence means the Codex overlay did not declare a skill directory Muse will import. The parenthetical is a phase limit. Hooks, MCP servers, and commands are not imported yet. They are not a substitute for the missing string, and they do not change the wording when the skill file is sitting next to the manifest.

hermes project show alpha and hermes project show nofolder listed the same primary. Both lines were the absolute path of one directory, LAB/repo. A third project, linkproj, listed LAB/link. That path was a symlink. readlink printed LAB/repo. stat -L reported inode 1750873 for the link and for the directory. stat without -L reported inode 1750871 for the symlink itself. Create had accepted the real path and the link as two projects. Add-folder had then stored the real path on the project that started with no folder. List printed four rows and did not say that two of those primaries were one string, or that the third string reached the same inode.

The order check exited 0. The totals line said the task fits, and the same line said every case flipped. File-order accuracy was 8 out of 8. The reordered answers were 0 out of 8. A script that stops at the exit code will treat a position-biased answer as a fit.

That run was not a call to TypeSafe, and it was not a claim about Jev 1.13.0. The binary was s1a probe from ThinkFlowLab/system1-agents at commit 0ee1165 (4 November 2026). The checkout’s pyproject.toml still says version 0.1.0. The changelog’s newest dated section is 0.3.0, dated 30 October 2026, which is where --order was added. The process ran on Linux x86_64 under Python 3.13.5, with openjiuwen 0.1.18 from the documented pin jj-0.1.0 (93f154e). No production key was present. A local HTTP stand-in answered the decisions shape the client posts, and it always returned the first key in criteria with a one-hot probability.

grok --sandbox devbox inspect --json exited 0. Stderr was empty. The JSON it printed had no sandbox field. The same run appended a row to sessions/sandbox-events.jsonl under the grok home:

event_type: ApplyFailed
profile: devbox
platform: linux/landlock
enforced: false
error: Landlock not available. Requires Linux kernel 5.13+ with Landlock enabled.

/sys/kernel/security/landlock was not on this host. /sys/kernel/security was. uname -r was 7.0.14-6-pve. The event sentence is not a version check. A kernel newer than 5.13 can still leave that sysfs node absent. /proc/config.gz and the matching /boot/config-* file were not there, so this note does not say which kernel option is missing. It says the node Grok’s own error names as the requirement was not present, and the command that asked for the profile still returned success.

hermes curator status counted one hand-written skill as curator-managed and agent-created. The pin command that had just written that skill’s record said the skill was unmanaged. hermes curator list-unmanaged still listed it. Those three prints came from one sidecar, one directory, and one build. They do not describe the same fact.

The curator page, read the same day, tells you to run hermes curator lock when a hand-authored skill must stay readable and must not be changed by the agent. On the installed launcher that word is not a curator subcommand. The process exits 2 before it looks for a skill, a directory, or a sidecar. Pin is the command this build actually has. Pin does not freeze the file. It also writes a record for a name that has no directory, and status does not show that record.

The permissions page tells you to pass --sandbox-network unrestricted when a Muse Code session should have full network access. It calls enabled the earlier name, and it says that earlier name still works. On Muse Code 1.4.14 the value unrestricted never starts a session. muse exec exits 2 and prints the three names it will accept: restricted, enabled, and proxy-only.

A later line, printed only after a session has started, tells you to install the distribution bwrap package. On this host that line tracked where the binary file resolved. It did not track whether bwrap was on PATH. The same file, with the same missing package, printed the line from /tmp and omitted it from a directory outside /tmp and outside TMPDIR. Both runs printed echo: ping and exited 0. Neither run executed a shell command.

permissionMode: yolo did not fail in one place. On Claude Code 2.1.308 it failed in the --agents flag, was logged and then ignored as a process result for a project agent file, and was loaded on purpose for a plugin agent. claude plugin validate passed the directory that held the illegal file. A job that treats that pass as a mode check is checking a different gate.

The three results are not three prints of one rule. The flag exits before it looks for a key. The project file writes a debug line and continues. The plugin file warns that the field is ignored, then loads the agent. Validate does not read the field in any of those files.

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.