This is a comment left during a code review.
Path: src/config/redact-snapshot.ts
Line: 703-715

Comment:
**Missing sensitivity guard on SecretRef restoration in guessing path**

In `restoreRedactedValuesGuessing`, the string-sentinel restoration (lines 697–702) is guarded by `!isExplicitlyNonSensitivePath(hints, [...]) && isSensitivePath(path)`, but the new SecretRef restoration block immediately below has no equivalent guard. This means any incoming object that happens to match the `isSecretRefShape` predicate (i.e. has `source: string` and `id: "__OPENCLAW_REDACTED__"`) at *any* path — including non-sensitive ones — will have its `id` silently replaced from the original config, even if the path is explicitly marked non-sensitive in `hints`.

The same inconsistency exists in the `!matched` branch of `restoreRedactedValuesWithLookup` (lines 651–662), where the string check includes `!markedNonSensitive && isSensitivePath(path)` but the new SecretRef block does not.

In practice the impact is low (a non-sensitive path would never have `id` set to `REDACTED_SENTINEL` by the redaction logic itself), but for consistency with the surrounding code the guard should be mirrored:

```
    } else if (typeof value === "object" && value !== null) {
      // Check if this is a SecretRef with redacted id field (#44357)
      const incomingObj = value as Record<string, unknown>;
      if (
        !isExplicitlyNonSensitivePath(hints, [path, wildcardPath]) &&
        isSensitivePath(path) &&
        isSecretRefShape(incomingObj) &&
        incomingObj.id === REDACTED_SENTINEL
      ) {
        const originalObj = toObjectRecord(orig[key]);
        if (isSecretRefShape(originalObj)) {
          result[key] = { ...incomingObj, id: originalObj.id };
        } else {
          result[key] = restoreRedactedValuesGuessing(value, orig[key], path, hints);
        }
      } else {
        result[key] = restoreRedactedValuesGuessing(value, orig[key], path, hints);
      }
    }
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/config/redact-snapshot.ts
Line: 630-641

Comment:
**Triplicated SecretRef restoration logic**

The same SecretRef detection + restoration block appears verbatim in three separate places:
1. `restoreRedactedValuesWithLookup` — matched branch (here, lines 630–641)
2. `restoreRedactedValuesWithLookup` — `!matched` / guessing fallback branch (lines 651–662)
3. `restoreRedactedValuesGuessing` (lines 704–715)

Extracting it into a small helper (e.g. `restoreSecretRefId`) would reduce the surface area for future divergence and make each call site easier to read:

```typescript
function restoreSecretRefId(
  incomingObj: Record<string, unknown>,
  originalValue: unknown,
): Record<string, unknown> | null {
  if (!isSecretRefShape(incomingObj) || incomingObj.id !== REDACTED_SENTINEL) {
    return null;
  }
  const originalObj = toObjectRecord(originalValue);
  if (!isSecretRefShape(originalObj)) {
    return null;
  }
  return { ...incomingObj, id: originalObj.id };
}
```

Each call site then becomes a simple `restoreSecretRefId(incomingObj, orig[key]) ?? <fallback>` check, making it easy to apply (or audit) the sensitivity guard mentioned in the adjacent comment uniformly.

How can I resolve this? If you propose a fix, please make it concise.