From 38870824add78ca2bda21402a7d0e514e44429ec Mon Sep 17 00:00:00 2001
From: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com>
Date: Thu, 17 Sep 2026 20:07:24 +0530
Subject: [PATCH] docs(config): the config RLock comment names its real reason

The comment said the lock is an RLock because save_config internally
calls read_raw_config. After the previous fix that is no longer true:
save_config takes its raw mapping from require_readable_config_before_write
and never re-enters the lock through read_raw_config.

The reentrancy that still exists is external: hermes_cli/plugins.py holds
_CONFIG_LOCK across its read-modify-write and then calls save_config(),
which acquires the lock again. Name that, and leave the RLock as is.
---
 hermes_cli/config.py | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/hermes_cli/config.py b/hermes_cli/config.py
index 3553ea6f98..8594bf93a5 100644
--- a/hermes_cli/config.py
+++ b/hermes_cli/config.py
@@ -187,7 +187,10 @@ def validate_env_var_name_for_write(key: str) -> None:
 # Serializes all config read/write paths and guards the module-level caches below. libyaml's
 # C extension is not thread-safe for concurrent safe_load() on one file, and tool threads
 # (approval, browser, setup flows) load/save config concurrently during long agent runs.
-# RLock because save_config internally calls read_raw_config.
+# RLock because callers hold it across a read-modify-write and then call save_config(), which
+# acquires it again (hermes_cli/plugins.py: `with ..., config_mod._CONFIG_LOCK:` then
+# read_user_config_raw() + save_config()). save_config itself no longer re-enters via
+# read_raw_config; it takes its raw mapping from require_readable_config_before_write.
 _CONFIG_LOCK = threading.RLock()
 # path -> last successfully loaded (expanded) config; served after a parse failure so a
 # mid-edit broken YAML never silently drops user overrides (e.g. approvals.deny rules).