Repository navigation
ISSUE-449: Track pack settings ownership per sub-key - #451
Merged
Merged
Conversation
- Record only the sub-keys a pack's settings file actually wrote, warning when an existing value wins - Project sync merges onto the user's settings.local.json instead of rebuilding it from empty - Narrow legacy whole-object records to the keys the pack declares, leaving unknown ones untouched
2 of 5 tasks
A pack whose settings values were all already set kept its previous settingsKeys, so removing it could delete a key another pack had since landed, and a legacy whole-object record was never replaced. Narrow the project-sync comment: array values such as permissions.allow are still owned whole. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CqExB5C9uXqPH2vKqj6dqa
- Project sync carries over existing extra keys only; hooks and plugins are still rebuilt from packs - Legacy expansion yields every declared path, the upper bound of what a sync could own
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A pack's settings file claimed whole top-level objects such as
env, so re-syncing or removing the pack deleted the user's own entries inside them. Packs now own only the sub-keys they actually wrote, and anything already set there is kept. Array values such aspermissions.alloware still owned as a whole (follow-up: #453).Closes #449
Release note
env,permissionsor other entries in the settings objects that pack also writes. When a pack's value clashes with one you already have, yours is kept and sync warns. A list value such aspermissions.allowstill belongs to whichever side set it first.Changes
settings.local.jsonextra keys (env,permissions, …) instead of rebuilding them. Hooks andenabledPluginsare still rebuilt from the packs, and the file is still removed when only those remain (tracked with Plugin enablement is written under a key Claude Code ignores, and project syncs install plugins globally #450)Test plan
swift testpasses locallyswiftformat --lint .andswiftlintpass without violationsAffected commands verified with a real pack (e.g.
mcs sync,mcs doctor)Add a user
envkey to~/.claude/settings.json,mcs sync --globaltwice with a pack whose settings file setsenv→ expect your key keptmcs pack remove <pack>→ expect only the pack's keys removed (Removed setting: env.<KEY>)Pack value differs from an existing one → expect a "was not applied" warning and the existing value kept
Two packs set the same
envvalue → removing the one that didn't land it keeps the keyChecklist for engine changes
LifecycleIntegrationTestsorDoctorRunnerIntegrationTests)🤖 Generated with Claude Code
https://claude.ai/code/session_01CqExB5C9uXqPH2vKqj6dqa