Repository navigation
Settings reset: an env-pinned key keeps its stored value beneath the pin, while the reset says the namespace is back on environment/default configuration #30664
Description
domain:server#2 · os-bill · session_01Utp6Cbvcmv8YWFhFJwzjKL
Filing gate: ③ a maintainer ruling that names this card: #30385 ruling A (Ruling confirmed on the card, maintainer 「同意」 2026-11-05T21:34Z), item 2 — "resetNamespace and the built-in reset action are not touched here … a separate p3 card; it does not block this one." Read by the seat in the cited file on main. ⛔ Not a claim. Suggested grade: p3.
Dedupe: reset env-pinned stored value, resetNamespace locked-by-env. Nearest: #30385 (the clear of an env-pinned key, PR #30448). New.
What happens
SettingsService.resetNamespace (packages/services/service-settings/src/settings-service.ts ~L3331) nulls the stored values of a namespace's keys but leaves env-locked keys untouched ("env wins over rows anyway and refuses writes"). The built-in reset action then answers "Cleared N saved value(s); environment/default configuration is back in effect." For an env-pinned key with a stored value, that value stays beneath the pin: the day the environment variable is removed, the stored value takes over again, which is the exact trap #30385 fixed for a single clear.
After PR #30448 a clear of an env-pinned key is allowed and sets its stored value to null, so the reason for skipping those keys in the reset is gone.
Expected
- The reset also clears the stored value beneath an env pin (the same
nullwrite fix(service-settings): a clear goes through an env pin, so the allowed-IP lockout recovery survives removing the variable #30448 allows), and changes nothing in force while the pin holds. - The reset's answer stays true: it counts what it cleared, and says when some keys are still pinned by the environment.
- Pins: an env-pinned key with a stored value is cleared by the reset and reads its default once the env var is gone; a non-pinned key behaves as today.
Reader: domain:server (service-settings). Serial: after PR #30448 and the ADR-0007 D6 amendment.
Activity
objectstack-fleet commentedon Nov 5, 2026
triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U
Path: none
Triage: audit · p3 kept ·
domain:server· 2026-11-05T21:55Z⛔ Not a claim.
Generated by Claude Code
objectstack-fleet commentedon Nov 6, 2026
domain:server#1 · os-elon-musk · session_016WV4cytLmJxfAmgPVjUbbW
Claim: PM loop round 4 · 2026-11-06T02:29Z
Session:
session_016WV4cytLmJxfAmgPVjUbbWAccount:
os-elon-musk(the seat's linked user asGET /useranswers it; the card's assignee)Branch:
claude/issue-30664-reset-clears-env-pinnedWorktree:
objectstack-issue-30664Domain:
domain:serverSeat:
domain:server#1File surface:
packages/services/service-settings/src/settings-service.ts(resetNamespace),packages/services/service-settings/src/settings-action-copy.ts(the reset answer, all eleven locales, only if its wording becomes false), their tests, one root.changeset/file. ⛔packages/spec/**,docs/adr/**,skills/**,.claude/**, the translation bundles #30512 is regenerating. Stop on breach and explain in the reportContainer & model:
S,mode:subagent,model: default,effort: mediumClause-②: no
Metadata-protocol: none
Responsibility:
SettingsService.resetNamespaceand the built-in reset action inservice-settings| resets skip env-pinned keys, leaving their stored value beneath the pin | an administrator who resets a namespace, then removes the env var and finds the old saved value back in forceThread-read: none
Premise: holds per the card (#30385 ruling A item 2); the dev re-reads
resetNamespace(~L3364) and the clear path PR #30448 opened onorigin/mainfirstSerial constraints cleared: PR #30448 merged; the ADR-0007 D6 amendment landed (#30698). Open PR #30720 touches
settings-service-plugin.ts, not these files; #30512's service-settings PRs touch its translation bundles, notsettings-action-copy.ts.