apply_servers() only writes mcpServers and _disabledMcpServers. Named server sets live in self.full_config under SETS_KEY (_bccServerSets), written there by save_server_set(self.full_config, ...).
So: user saves a named set → an external process touches the config → user hits Save → Merge → the set is never carried into fresh, and then self.full_config = fresh drops it from memory too. No warning, no backup prompt, gone.
Severity
Same class as the drag-and-drop silent-overwrite fixed in #8: quiet data loss on a path the user explicitly chose because it sounded safe. "Merge" implies keeping the user's work.
Note external_change_summarydoes compare all top-level keys, so _bccServerSets shows up in changed_keys when the disk copy differs — but that reports it as an external change; it doesn't stop the local one being dropped.
Suggested fix
Decide the merge semantics for BCC-owned keys explicitly, rather than by omission:
Preferred: carry BCC-owned keys (SETS_KEY, and anything else BCC authors) from self.full_config onto fresh before writing — BCC is the owner of those keys, so local wins.
If disk also changed SETS_KEY, that's a genuine conflict worth surfacing in StaleDialog rather than silently picking a side.
Consider making this generic: a BCC_OWNED_KEYS tuple consulted by the merge, so the next BCC-authored key doesn't reintroduce the same bug.
Tests
Config with _bccServerSets in memory + an external write to disk + Merge → the set survives in the written file. Add the symmetric case where disk changed the sets too.
## What
In the stale-file **Merge & save** branch (bcc.py ~L2475):
```python
fresh = core.load_config(self.current_profile.path)
core.apply_servers(fresh, self.servers)
...
self.full_config = fresh
```
`apply_servers()` only writes `mcpServers` and `_disabledMcpServers`. Named server sets live in `self.full_config` under `SETS_KEY` (`_bccServerSets`), written there by `save_server_set(self.full_config, ...)`.
So: user saves a named set → an external process touches the config → user hits Save → Merge → the set is **never carried into `fresh`**, and then `self.full_config = fresh` drops it from memory too. No warning, no backup prompt, gone.
## Severity
Same class as the drag-and-drop silent-overwrite fixed in #8: quiet data loss on a path the user explicitly chose because it sounded safe. "Merge" implies keeping the user's work.
Note `external_change_summary` *does* compare all top-level keys, so `_bccServerSets` shows up in `changed_keys` when the disk copy differs — but that reports it as an external change; it doesn't stop the local one being dropped.
## Suggested fix
Decide the merge semantics for BCC-owned keys explicitly, rather than by omission:
- Preferred: carry BCC-owned keys (`SETS_KEY`, and anything else BCC authors) from `self.full_config` onto `fresh` before writing — BCC is the owner of those keys, so local wins.
- If disk *also* changed `SETS_KEY`, that's a genuine conflict worth surfacing in `StaleDialog` rather than silently picking a side.
- Consider making this generic: a `BCC_OWNED_KEYS` tuple consulted by the merge, so the next BCC-authored key doesn't reintroduce the same bug.
## Tests
Config with `_bccServerSets` in memory + an external write to disk + Merge → the set survives in the written file. Add the symmetric case where disk changed the sets too.
the_og
added the P1 label 2026-07-20 12:07:09 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What
In the stale-file Merge & save branch (bcc.py ~L2475):
apply_servers()only writesmcpServersand_disabledMcpServers. Named server sets live inself.full_configunderSETS_KEY(_bccServerSets), written there bysave_server_set(self.full_config, ...).So: user saves a named set → an external process touches the config → user hits Save → Merge → the set is never carried into
fresh, and thenself.full_config = freshdrops it from memory too. No warning, no backup prompt, gone.Severity
Same class as the drag-and-drop silent-overwrite fixed in #8: quiet data loss on a path the user explicitly chose because it sounded safe. "Merge" implies keeping the user's work.
Note
external_change_summarydoes compare all top-level keys, so_bccServerSetsshows up inchanged_keyswhen the disk copy differs — but that reports it as an external change; it doesn't stop the local one being dropped.Suggested fix
Decide the merge semantics for BCC-owned keys explicitly, rather than by omission:
SETS_KEY, and anything else BCC authors) fromself.full_configontofreshbefore writing — BCC is the owner of those keys, so local wins.SETS_KEY, that's a genuine conflict worth surfacing inStaleDialograther than silently picking a side.BCC_OWNED_KEYStuple consulted by the merge, so the next BCC-authored key doesn't reintroduce the same bug.Tests
Config with
_bccServerSetsin memory + an external write to disk + Merge → the set survives in the written file. Add the symmetric case where disk changed the sets too.the_og referenced this issue2026-08-03 22:41:03 -04:00