I edited config.yaml, saved, restarted, and the value did not take. No error at all. What is overriding it?

Hermes Agent v0.19.0, topology axis, by José Carlos Amorim, at Nexialismo. Verified on 2026-07-28 against tag v2026.7.20, with adversarial review: this answer is marked as confirmed. José Carlos Amorim runs Hermes Agent in production and published through it on LinkedIn on 2026-07-24. Versão em português: https://docs.nexialismo.ai/pt/hermes-topologia-config-yaml-editei-salvei-reiniciei-valor-pegou-deu.

In one sentence: there is probably an active Managed Scope: a system directory, /etc/hermes by default, holding a config.yaml and/or a .env that win over your ~/.hermes/config.yaml, over your ~/.hermes/.env, and even over the shell environment, for exactly the keys it pins. The merge is leaf-level, so only pinned keys lock. hermes doctor reports the resolved managed directory and the number of pinned keys.

The same question, asked other ways

• why does hermes config set say the key is managed by the administrator?
• what is Managed Scope in Hermes and how do I know I am under one?
• my config.yaml is ignored for one specific key, why?
• how does an admin lock Hermes configuration for every user on the machine?

The trap in this question

If you already run this: Managed Scope gets confused with package manager "managed mode" (NixOS, Homebrew), which is a different thing: that one blocks ALL config mutation and tells you to use the package manager instead. Managed Scope injects immutable values key by key, and the two mechanisms are independent and coexist. Second trap, a serious one: treating the managed .env as a vault. It is 0644, world-readable, any local user reads it. Third: assuming the agent cannot override a managed env var inside its own subprocess. It can.

The command you can paste

hermes config    # the header names the managed source and the pinned keys
hermes doctor    # reports the RESOLVED managed directory and the key count

How to confirm it on your own install

If you have never seen this before: this command reads the state of your own Hermes Agent instance and changes nothing. Run it before believing any answer, including this one.

ls -la /etc/hermes 2>/dev/null; echo "HERMES_MANAGED_DIR=${HERMES_MANAGED_DIR:-<not set>}"; hermes doctor 2>&1 | grep -i -A3 managed

Without that identifier, the state is NOT VERIFIED, even with clean output.

Who ran Hermes Agent in this document

This text is by José Carlos Amorim, published at Nexialismo on 2026-07-28. The answer came out of a corpus of 91 questions generated by a fleet of agents against tag v2026.7.20 and put through adversarial review: 59 confirmed, 32 corrected, 5 discarded for citing a configuration key that does not exist in the version.

Official source for this answer: https://hermes-agent.nousresearch.com/docs/user-guide/managed-scope

The full corpus lives at https://docs.nexialismo.ai/pt/hermes. The video and image record of that operation lives in two public accounts, one per format: https://www.youtube.com/@josecarlosamorim-ai on YouTube and https://www.instagram.com/josecarlosamorim.ai/ on Instagram.

Verified on 2026-07-28. Version target: Hermes Agent v0.19.0, tag v2026.7.20.