154 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Cowork SupervisorandClaude Opus 4.8	2e5d0351b4	test(#91): assert sidecar paths via as_posix() for the Windows CI runner ... The CI matrix includes a windows-latest job where str(Path("/Users/…")) renders with backslashes, so the platform-parameterised sidecar-path assertions failed there (macOS/Linux passed). Compare .as_posix() instead — separator-normalised and portable — and note why. Pure test fix; no production-code change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-12 03:07:47 -04:00
Cowork SupervisorandClaude Opus 4.8	8c51c25211	feat(#91): sidecar config detection + precedence + verified paths ... ssh-mcp v2 reads a TOML sidecar and only falls back to CLI args when that file is ABSENT — so BCC's managed --host/--user args can be completely inert while the real config lives in a file BCC never looks at. This adds read-only truth-telling for that (no sidecar writing). Core (pure, fully injectable platform/environ/home/exists/read for testing): - sidecar_path(spec): VERIFIED per-platform TOML location from the package source, NOT the README (macOS → ~/Library/Application Support/ssh-mcp, Windows → %APPDATA%, else → ${XDG_CONFIG_HOME:-~/.config}). sidecar_doc_path() is the README path. - sidecar_status(): resolves exists / has_managed_args / args_inert / wrong_path. - sidecar_warnings(): mirrors removed_flag_warnings' shape. Reports: * precedence — "these arguments are inert; the server reads <real path>" * wrong-path — a TOML at the README path the server never actually reads * #11 credential scoping — an unprefixed SSH_MCP_PASSWORD shared across 2+ profiles in a multi-profile sidecar (count_toml_profiles is a documented 3.10-safe heuristic; unscoped_credential_warning gates on it). GUI: a read-only advisory label in the stdio editor (mirrors the removed-flag label; no fix button — editing the sidecar is a separate deliberate action). Uses the real platform/env/filesystem so it reflects this machine. pytest green, ruff + format clean. Closes #91. Part of epic #94. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-12 02:59:49 -04:00
Cowork SupervisorandClaude Opus 4.8	e087107710	feat(#90): promote FLAG_ENV_MIGRATIONS into a ServerSpec spine ... Introduce the server-package axis (orthogonal to ClientSpec): a frozen ServerSpec dataclass + SERVER_SPECS registry that the sidecar (#91), version-pin (#92) and permission (#93) work all hang off. - ServerSpec carries env_flags / removed_flags / drift_flags / sidecar_paths / sidecar_doc_path / schema. FLAG_ENV_MIGRATIONS is now a derived view of the registry, so every existing reader and the migration functions keep the exact shape #89 shipped — the migration LOGIC is unchanged, only the DATA grew. - resolve_server_spec(data) is the ServerSpec entry point; detect_migratable_package is a thin name-only wrapper over it (behaviour identical). - Add the verified #4 follow-ups: --sudoPassword AND --suPassword now auto-migrate to SSH_MCP_SUDO_PASSWORD (two flags → one var; existing no-clobber handles it). --disableSudo stays warn-only (sudo is now a role/policy, no env replacement). - Add drift_warnings(): --maxChars=none changed meaning (v1 silently capped at 5000 chars). Warn-only, no auto-fix; matches inline and separate arg forms. - Seed ssh-mcp's verified per-platform sidecar TOML paths and zod enums (auth/approvalMode/role/port) as data for later issues. Pure core + tests, no GUI. One #89 test (sudoPassword now migratable) updated to reflect the intended data growth, with a comment citing the verified facts. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-12 02:54:42 -04:00
the_og	436524bf00	Merge pull request 'feat(#88): detect & migrate removed CLI flags into env (ssh-mcp v2)' (#89) from feat/removed-flag-env-migration into main	2026-08-12 02:13:02 -04:00
the_og	e542ff6e8f	Merge remote-tracking branch 'origin/main' into feat/removed-flag-env-migration ... # Conflicts: # tests/test_core.py	2026-08-12 06:12:19 +00:00
the_og	dc9e035781	Merge pull request '"Move to environment variable" — convert a plaintext secret to ${VAR} (#83)' (#87) from feat/83-move-to-env-var into main	2026-08-12 02:10:56 -04:00
the_og	7368dcdbff	feat(#88): detect & migrate removed CLI flags into env (ssh-mcp v2) ... ssh-mcp v2 removed --password from the command line and reads SSH_MCP_PASSWORD instead, so an old config crashes on startup. Add a data-driven FLAG_ENV_MIGRATIONS registry plus detect_migratable_package, migrate_removed_flags and removed_flag_warnings in bcc_core, and a 'Fix: move to environment variables' one-click action + warning in the stdio server editor, with a matching main-window lint line. The literal value lands in env{} (the only form Claude Desktop honours). 14 tests.	2026-08-11 16:02:11 +00:00
the_ogandClaude Opus 4.8	694439b6f3	feat(#83): variables readout, two clear move actions, args->env relocation ... Field testing showed the feature was doing the right thing but describing it wrong, and left the moved variable invisible. Reworked per that feedback: Naming. "Move to environment variable" read like "move into the Environment variables table"; it actually creates a ${VAR} reference to the shell/OS environment. Renamed the action to "Replace with a ${VAR} reference (out of file)…" everywhere, and the dialog now says plainly the secret goes to your shell environment -- not this file, not the table below. Visibility (the real gap). A lone ${SECRET_KEY} with nothing saying whether it's wired up isn't much better than a mystery. New Variables… button opens ReferencedVarsDialog: every ${VAR} the loaded server references, each with ✓ set / ✓ default / ✗ not set and the exact export/setx line to set it. Backed by pure core.referenced_env_vars (dedupes across fields, resolves against a given environment or a default). Two actions on an args secret, because the user may want either: * "Replace with a ${VAR} reference (out of file)…" -- secret leaves the file (needs a client that expands refs; disabled with reason on Desktop). * "Move into Environment variables (kept in this config)…" -- relocates the arg into the env block where it's visible and editable. Works on any client (no ${VAR} needed). core.move_arg_to_env_block drops the flag+value and sets env[VAR]; the dialog warns it changes how the server launches. Both args actions run through ServerEditor (moving into env touches args AND the env table), which reloads the form from the transformed data. Tests: +10 core (referenced_env_vars dedupe/status/default; move_arg_to_env_block flag+value removal, bare positional, None on bad target). 488 passed, ruff clean. New dialogs/menus are GUI, untestable in CI as before. Refs #83 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EKwBecy6N83jnqQmw8ezwE	2026-08-04 04:25:28 +00:00
the_ogandClaude Opus 4.8	4743c4a995	feat(#83): offer move-to-env on args rows; explain the gate instead of an empty menu ... Two things surfaced testing the GUI: 1. Args rows showed the secret warning but no move action -- the args editor is a free-text widget, not a table, and was deliberately left out of the first cut. Wired it up: ArgsEdit gains a context menu that offers "Move to environment variable…" on exactly the args that look like a credential. New pure core: secret_arg_indices (which args are secrets, mirroring args_secret_warning per-index) and suggested_env_var_for_arg (default var name from the preceding flag -- `--api-key <secret>` -> API_KEY, else SECRET). The move replaces that one arg line with ${VAR} and copies the secret to the clipboard, same contract as the tables. 2. On a Claude Desktop profile (or any non-expanding client) the menu showed NOTHING, so it read as broken. Now a real stored secret always shows the item -- enabled on a client that expands references, or disabled with the reason ("unavailable for Claude Desktop -- it doesn't expand ${VAR}") so the gate is visible rather than silent. Applies to env, headers and args. Not a change: after converting, env_ref_warnings still notes a variable that isn't set in the environment. That's #82's advisory doing its job -- the user runs the export line the dialog handed them; auto-adding a ':-default' would bake a fallback back into the config and defeat moving the secret out. Tests: +5 core (secret_arg_indices for token/flag-value/embedded-URL/ reference-excluded, suggested_env_var_for_arg with and without a flag). 483 passed, ruff clean. GUI wiring (context menus) remains untestable in CI. Refs #83 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EKwBecy6N83jnqQmw8ezwE	2026-08-04 04:03:47 +00:00
the_ogandClaude Opus 4.8	8fdbe90b37	feat: "Move to environment variable" — convert a plaintext secret to ${VAR} (#83) ... Follow-up to #76/#82: BCC warns when a config holds a raw credential and points at ${VAR}, but gave no way to make the change. This adds the one-click conversion, right-click a secret row in the env or headers table. The value is about to leave the file, so the action's real job is handing the secret back before it does: - Core (pure, tested): sanitize_env_var_name (key -> legal upper-case shell name; 'api-key' -> API_KEY, '2fa' -> _2FA, non-ASCII/empty handled), shell_export_lines (the exact export/setx line, POSIX single-quoted safely), move_value_to_env_ref (data in -> new data out, replaces one env/header/args value with ${VAR}, returns the removed secret; never mutates the input; None if the target is missing, non-string, or already a reference), can_move_value_to_env_ref (offer only a real stored secret, not already a ref, AND only on a client that expands references -- offering it on Claude Desktop would author a config that reaches the server as literal ${VAR}, the exact failure #76 exists to prevent), and is_env_var_set (skip the ceremony when the variable already looks set). - GUI: KeyValueTable gains a context menu gated on can_move_value_to_env_ref (so it never appears on a non-secret row or a Claude Desktop profile). MoveToEnvDialog lets the user name the variable (defaulting to the sanitised key), shows the platform-appropriate shell line live, notes when the variable already looks set, and on accept copies the secret to the clipboard before the cell is replaced with the reference. Wired through ServerEditor.set_profile_provider so the tables know which client is loaded. Scope note: env and headers rows for now. The core already handles args by index; wiring the args editor (a free-text widget, not a table) is a small follow-up, deliberately not bundled here. Tests: +15 core (name sanitisation incl. non-ASCII/leading-digit/empty, POSIX quote safety, the gate across secret/non-secret/already-ref/ non-expanding-client, env+headers+args rewrite, input-not-mutated, missing/non-string/already-ref -> None, is_env_var_set). 478 passed, ruff clean. GUI is untestable in CI (no PySide6); the decision logic all lives in bcc_core and is tested there. Closes #83 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EKwBecy6N83jnqQmw8ezwE	2026-08-04 03:43:21 +00:00
the_og	072a5cdc08	Merge PR #86: disambiguate project profiles with the same basename (#74) ... Two repos both named "app" no longer both render as "Project: app": disambiguate_project_labels widens colliding labels toward the root (Project: work/app vs personal/app), discover_project_configs now requires a .mcp.json that parses to a dict (skipping arrays/garbage that only failed on open), and the full path goes in the combo tooltip. Pure core + 6 tests; the only GUI change is one setItemData line. 463 passed, ruff clean, CI green incl. Windows. Closes #74	2026-08-03 23:42:18 -04:00
the_ogandClaude Opus 4.8	0191a93eb9	fix: disambiguate project profiles that share a directory basename (#74) ... discover_project_configs labelled every project by basename alone, so ~/work/app/.mcp.json and ~/personal/app/.mcp.json both read as "Project: app". Paths dedupe correctly, so both profiles existed -- they were just indistinguishable in the picker, and picking the wrong one meant editing, backing up, and writing the wrong repo's config. api/web/app/ server/client as repo names make this common. - disambiguate_project_labels(dirs): pure, testable. Labels stay "Project: <name>" until a basename collides, then only the colliding ones widen toward the root one component at a time ("Project: work/app" vs "Project: personal/app"), widening further if the parent also collides. The common no-collision case is unchanged. - Full path goes in the combo item's ToolTipRole, so a profile is always verifiable by hover regardless of label. - Tightened the "is this a project config?" check: the docstring claimed a top-level object but the code only checked is_file(), so a .mcp.json that was a JSON array or garbage still became a profile and only failed on open. It now must parse (strict) to a dict, else it's skipped. Tests: +6 (no-collision basename, colliding widen, deeper widen, and discover_project_configs disambiguation + skipping array/garbage/missing). 463 passed, ruff clean. Closes #74 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EKwBecy6N83jnqQmw8ezwE	2026-08-04 03:29:13 +00:00
the_og	5add9b0ce0	Merge PR #85: ClientSpec adapter refactor — cross-client phase 1 (#5) ... Phase 1 of cross-client support: introduce the ClientSpec adapter and route Claude Desktop + Claude Code through it with no behavior change. Parameterizes servers_key/disabled_key/discovery and the entry translation seam; extract_servers/apply_servers/_server_sections/external_change_summary default to Claude's layout so no-spec calls are byte-identical. Verified: 458 tests + a synthetic non-mcpServers client proving the seam generalizes, CI green on all platforms incl. Windows, and the live GUI confirmed loading/saving identically. requirements.txt now declares cryptography as the runtime dep it always was. Refs #5	2026-08-03 23:19:56 -04:00
the_ogandClaude Opus 4.8	57fd3cb6e3	fix: declare cryptography as a runtime dependency ... bcc_core imports cryptography at module load (catalog signature verification), so it's required to even start the app -- but requirements.txt listed only PySide6, so a from-source run died with ModuleNotFoundError: No module named 'cryptography'. The frozen release builds were unaffected because PyInstaller follows the import, which is why this never surfaced until someone ran the GUI from source to review this branch. Move cryptography into requirements.txt (runtime) and re-label it in requirements-dev.txt as runtime rather than test-only; the version pin is unchanged (>=42.0). Refs #5 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EKwBecy6N83jnqQmw8ezwE	2026-08-04 03:17:09 +00:00
the_ogandClaude Opus 4.8	4a95b370b9	refactor: introduce ClientSpec adapter; route Claude Desktop + Code through it (#5) ... Cross-client support (Cursor / Windsurf / VS Code) was blocked on Claude's layout being hard-coded throughout the code: servers always under the literal "mcpServers" key, a fixed set of Claude file locations, and "which client is this?" answered by sniffing a filename. Adding a client that differs on any of those axes meant chasing those assumptions through a dozen sites. This is phase 1 of #5: the keystone refactor, with NO behaviour change. It adds a ClientSpec adapter that captures the three things that vary across clients -- the top-level servers key, the config discovery paths, and the per-server value shape -- plus the capability flags that were previously computed inline from a filename (does the client expand ${VAR}? can we offer Restart?). - ClientSpec (frozen dataclass): servers_key, disabled_key, config_filename, expands_env_refs, supports_restart, and entry_to_internal/entry_from_internal -- the per-server translation seam, identity for any mcpServers-shaped client, the single point a differently-shaped client (VS Code's type/inputs form) overrides. - CLAUDE_DESKTOP and CLAUDE_CODE specs; both use mcpServers + the existing parking key, so their translation is the identity and nothing changes for today's users. resolve_client(path) reproduces the old filename rule exactly; each Profile now carries its resolved .client. - extract_servers / apply_servers / _server_sections / external_change_summary take an optional spec and default to Claude's layout, so every existing call site and test that omits a spec is byte-for-byte unchanged. The cardinal rule now generalises: apply_servers only ever writes the client's own two keys, parameterised rather than hard-coded. - profile_targets_claude_desktop and client_expands_env_refs are now thin reads off the profile's spec -- one source of truth for client identity instead of scattered filename checks -- with identical answers. - GUI: the load, Copy-to, save and stale-merge paths pass the profile's spec into the core calls. Mechanical; no logic moved into bcc.py (which CI can't test -- no PySide6). Tests: +14. Existing suite unchanged and green (behaviour preservation). A synthetic non-mcpServers spec ("servers" key, a different disabled key, a per-server `type` field) exercises the whole pipeline -- extract, apply, masking, external-change diff -- proving the seam actually generalises before any real client depends on it. 458 passed, 1 skipped; ruff clean. Refs #5 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EKwBecy6N83jnqQmw8ezwE	2026-08-04 02:53:51 +00:00
the_og	f168079755	Merge PR #82: author ${VAR} references, gated on client expansion (#76) ... Adds the authoring + safety layer for ${VAR} references: expand_env_refs preview, per-client gating via profile_targets_claude_desktop (Claude Code expands natively, Desktop does not), and fixes two backwards behaviours (masking hid placeholders; args_secret_warning fired on the recommended fix). BCC never expands on write. 444 tests, ruff clean. Closes #76	2026-08-03 22:41:06 -04:00
the_og	a73f2e3883	feat: author ${VAR} references, gated on whether the client expands them (#76) ... The blocker on this issue was whether BCC or the client does the expanding. Answer, from Anthropic's docs: Claude Code expands ${VAR} and ${VAR:-default} itself, in command, args, env, url and headers, for both project .mcp.json and user-scope ~/.claude.json. Claude Desktop has no documented support. So this is a per-client capability, not a global one, and BCC does NOT expand on write: resolving a reference into the file would put the secret back on disk -- the whole thing the user is avoiding -- and would defeat a feature the client already implements correctly. BCC authors, validates and warns; expand_env_refs exists to preview what the client will do. Semantics mirror the documented ones exactly, including the unusual bit: an unset variable with no default is left as literal ${VAR} text rather than blanked, because that is what Claude Code passes through. Gating uses the existing profile_targets_claude_desktop(), so a config that is correct under Claude Code and broken under Desktop is reported against whichever profile is actually loaded. The two warnings are worded differently on purpose -- 'this client will never expand these' is a different problem from 'this variable looks unset here'. Two existing behaviours were backwards for this feature and are fixed: - Secret masking hid placeholders. is_secret_key('API_KEY') is true, so ${API_KEY} rendered as dots -- making a reference indistinguishable from a stored credential, which is the one distinction that makes the feature worth adopting. should_mask_value() now skips references, in the table delegate, _redact_server_data and redact_args alike. - args_secret_warning fired on placeholders. Moving a token into ${VAR} is the recommended fix for that warning; continuing to warn punished the fix. It now skips references while still flagging a real secret that follows one. Real secrets are still masked everywhere they were before -- asserted, not assumed. Refs #76	2026-07-20 13:46:14 -04:00
the_og	7ff4f6e5c0	Merge PR #81: make the update checker visible — persistent banner + Help menu item (#78, #79)	2026-07-20 12:52:48 -04:00
the_og	7517e16b15	Merge branch 'main' into fix/78-79-update-visibility ... Three conflicts, two of them semantic rather than textual: - bcc.py QSS: this branch added the noticeBanner rules using the old module-level constants ({MUTED}, {ACCENT}); main had since moved the stylesheet onto palette slots ({p.muted}). Took main's form and translated the notice rules into it -- picking either side wholesale would have either dropped the banner styling or reintroduced globals that test_stylesheet_builder_has_no_hardcoded_colours now forbids. - bcc.py methods: both sides appended to MainWindow (update-notice handlers vs theme handlers). Additive, kept both. - tests/test_core.py: the usual EOF append. Kept both blocks. _build_menu_bar auto-merged cleanly (View menu above, Help menu below); verified both are present with their menu roles intact. Verified: 272 test functions = 265 (main) + 7 (this branch), no duplicates; 421 passed, ruff clean.	2026-07-20 12:51:55 -04:00
the_og	9a0433225e	Merge PR #80: light theme + system-following, dark preserved exactly (#75)	2026-07-20 12:51:01 -04:00
the_og	fa82d30087	Merge branch 'main' into feat/75-theming ... Union conflict at the end of tests/test_core.py -- both branches appended a test block. Kept both, main's #72/#73 block first. Verified: 265 test functions = 238 baseline + 15 (#77) + 12 (theming), no duplicates.	2026-07-20 12:50:09 -04:00
the_og	05b00a40c0	Merge PR #77: tolerate non-object server values; keep named sets across a merge (#72, #73)	2026-07-20 12:49:23 -04:00
the_og	3068e74e5c	fix: make the update checker visible -- persistent banner + a menu item ... Reported from the field: running v1.2 against a repo with v1.3.0 published gave no prompt, and there appeared to be no way to check manually. The checker itself works; it was invisible, for two reasons. #78 -- the notice was written to the shared status label, which 21 other call sites rewrite. The check runs off-thread and lands a second or two after launch, right as the user starts clicking, so the next selection or refresh wiped it. Exactly the bug fixed for the MSIX warning in #35, which got a persistent banner; that fix was never carried to the update notice. Adds NoticeBanner: a persistent, dismissible notice carrying its own action button. It's a shared widget rather than a second bespoke banner, so the next thing needing the user's attention doesn't reach for the status bar again. (The MSIX banner still uses its own QLabel -- migrating it is a follow-up, deliberately not bundled with a bug fix.) #79 -- the only 'Check for updates' affordance was a button inside the About dialog, which is not where anyone looks. Worse, the About action was created without a menu role, and Qt auto-assigns AboutRole to actions whose text begins with 'About', relocating it into the macOS application menu -- so the notice's own hint, 'Help > About to view it', pointed at a menu that on macOS doesn't contain the item. Help now has its own 'Check for updates...' item with an explicit ApplicationSpecificRole, and the About action states its AboutRole rather than inheriting it invisibly. The menu-driven check is never throttled and always reports back -- the user asked, so silence would read as broken. The decision and the wording live in core.update_notice() because the test suite has no PySide6 (CI installs pytest + cryptography only), so anything in bcc.py is untestable. A test asserts the notice text names no menu path, which is what went stale here in the first place. Closes #78 Closes #79	2026-07-20 12:29:37 -04:00
the_og	febd617c56	feat: light theme + system-following, with the dark theme preserved exactly ... BCC has always been dark-only -- BG #1b1d23, hardcoded at import time, with no light option and no awareness of the desktop's appearance. On a light desktop it matches nothing else on screen and there was no way to change it. Adds a Palette value type in bcc_core with DARK (byte-identical to the colours v1.3.0 shipped) and a new LIGHT, plus resolve_theme(setting, system_is_dark) so the decision is testable without a Qt app. View > Theme offers Match system / Light / Dark, persisted in QSettings under ui/theme, defaulting to following the system. The light palette's semantic colours are deliberately not the dark ones lightened: #4ade80 sits near 1.7:1 against white. They are darkened to clear WCAG AA, and a contrast test enforces >= 4.5:1 for every text colour against its surface in both palettes so nobody harmonises them back later. Three near-black literals were baked into the stylesheet (#1a1205 on-accent text, #202229 disabled table, #16181d diagnostics pane). Fine with one theme, invisible breakage with two -- each now has a palette slot, and a test asserts build_stylesheet contains no hex literals at all. The ~20 inline setStyleSheet(f"color: {MUTED}") call sites are left alone: apply_palette rebinds the module-level colour names, and an f-string resolves its names when it runs, so each call site picks up the new colour on its next render. Switching theme reapplies the global QSS and re-renders the inline-styled widgets, so nothing is left dark-on-light. Refs #75	2026-07-20 12:22:38 -04:00
the_og	da20eb2fdb	fix: tolerate non-object server values on load; keep named sets across a merge ... Two silent-failure bugs found auditing the v1.3.0 features. #72 -- extract_servers called dict() on every server value, so a config that was valid JSON but held a non-object server ("foo": "oops", a number, a list, null) raised on load. The strict parse succeeded, so the repair path never saw it, and the call sat outside the load try/except: an unhandled traceback with the window half-swapped to the new profile. It also made the #54 schema lint unreachable for the most likely hand-edit mistake -- the load died before the linter ran. Malformed values are now preserved verbatim on ServerEntry.raw (behind a NO_RAW sentinel, since a literal JSON null is itself a malformed entry worth keeping) and written back untouched on Save, so nothing is silently deleted. lint_servers names the offending entry instead. #73 -- the stale-file "Merge & save" path reloaded the file from disk and re-applied the user's servers, but apply_servers only writes mcpServers and _disabledMcpServers. Named server sets live under _bccServerSets in the same file, so a set saved that session was dropped from disk and then from memory, with no warning, on the path the user picks because it sounds like the safe one. BCC-owned keys are now declared in BCC_OWNED_KEYS and carried across by carry_owned_keys, which reports genuinely contested keys so the status line can say so. Deliberately one-directional: a key absent locally is left alone on disk, because 'user deleted their last set' and 'another machine just added sets' are indistinguishable and deleting someone else's data is the worse failure. Closes #72 Closes #73	2026-07-20 12:11:49 -04:00
the_og	cd2ac2f6f8	Merge PR #69: make the review gate load-bearing, split the keys (#68) ... Finding 1: can_sign() returned True on an empty changeset, and _on_sign compared the reviewed blob against a hardcoded "main" rather than the ref actually reviewed — so the PR path could never sign, and the main-vs-main path unlocked Sign with zero entries acknowledged. That is how commit b08cf21 signed 19 entries nobody reviewed. can_sign now refuses an empty diff, checks has_blocking_risk itself instead of trusting a GUI checkbox, and resolves the TOCTOU pin from the reviewed ref via a pure, testable sign_precondition(). Finding 5: the catalog key and the release key are now separate. The release key lives in CI and signs checksums; the catalog key stays offline and signs what users execute. A CI compromise gets the former, not the latter.	2026-07-12 21:30:13 -04:00
the_og	26c66b7db1	Merge branch 'main' into fix/68-console-gate	2026-07-12 21:28:27 -04:00
the_og	86139100eb	Merge PR #70: enforce the checks we said we had (#68) ... Findings 2/3/4/6/7. config.env now gets the deny-list, ASCII, secret and empty-or-placeholder checks that args always had; version pinning is enforced at runtime, not only in the maintainer tool; the CI gate pins the expected pubkey instead of trusting the one in the PR it is reviewing; resolve_catalog anchors its cap to the bundled version and prefers bundled on ties; catalog ids are constrained. Tests rewritten: the old fixtures asserted the unpinned form validates clean and that config.env passes through verbatim — they enshrined two of the bugs.	2026-07-12 21:28:24 -04:00
BCC Agent	38f14deeff	fix(core): validate config.env, enforce version pinning, fix CI trust anchor and resolve_catalog guards (#68) ... Fixes findings 2, 3, 4, 6, 7 from the issue #68 adversarial review. - Finding 2: config.env was type-checked only. Add CATALOG_DENIED_ENV_KEYS (case-insensitive) for interpreter/loader-override keys (NODE_OPTIONS, PYTHONPATH, LD_PRELOAD, ...), apply the ASCII check and the existing secret-value check to env keys/values, and require env values to be empty or a single <PLACEHOLDER> token. - Finding 3: version pinning was only checked by catalog_review.py (which never runs on the signing path per finding 1). Move enforcement into _validate_catalog_config: npm/uvx specs must carry @version or ==version (scoped names handled), docker images must have an explicit non-latest tag. Only the first plausible package-spec token is checked, so flags, <PLACEHOLDER>s, and docker subcommands/flags don't trip it. All 19 real catalog entries still validate clean. - Finding 4: the CI catalog-signature gate imported bcc_core from the PR branch and trusted whatever CATALOG_PUBKEYS said there, so a PR changing both catalog.json and CATALOG_PUBKEYS (with a matching signature) went green. ci.yml now hardcodes the expected base64 pubkey and asserts bcc_core.CATALOG_PUBKEYS matches it before verifying the signature. NOTE: the maintainer is planning to rotate this key -- update EXPECTED_CATALOG_PUBKEY_B64 in ci.yml as its own reviewed change when that happens, never bundled with a catalog content change. - Finding 6: resolve_catalog's anti-rollback/anti-freeze guards sat behind `if best_version >= 0`, so the first verified candidate was accepted unconditionally and the anti-freeze anchor drifted with each accepted candidate instead of staying fixed. The cap is now measured against the bundled catalog's version specifically (the trust anchor baked into the binary), regardless of evaluation order; bundled wins version ties; and a new pure `floor` parameter lets a future caller pass a persisted accepted-version floor. - Finding 7: catalog id is now constrained to ^[a-z0-9][a-z0-9._-]{0,63}$. Tests: fixed _minimal_catalog to use a pinned package (was enshrining finding 3), rewrote the env-passthrough test to prove the validation boundary instead of asserting env passes through unchecked, and reordered test_resolve_catalog_rejects_absurd_version_jump so it actually exercises the first-candidate path. Added positive/negative tests for every new rule. Manually verified each new check by commenting it out and confirming the guarding test goes red, then restoring it.	2026-07-12 21:27:08 -04:00
BCC Fix Agent	82483e693d	fix(catalog-console): close the vacuous review gate; split catalog/release signing keys ... Fixes #68 findings 1 and 5. Finding 1 -- the review gate signed without reviewing anything: - ReviewWindow._on_sign hardcoded "main" as the TOCTOU comparison ref, so any PR review (where _on_load pins the PR head's blob SHA) could never sign; the only working path was main-vs-itself, whose empty diff made can_sign() vacuously True (set() <= set()). Commit b08cf21 signed 19 entries through exactly that path with zero of them reviewed. - can_sign() now refuses an empty changeset outright, and itself checks has_blocking_risk() across every changed entry rather than trusting the GUI to have disabled a checkbox. - ReviewSession now carries loaded_ref (the exact ref reviewed); a new pure sign_precondition(session, resolve_blob_sha) resolves the TOCTOU SHA from that ref, never a hardcoded "main". _on_load's retry path re-diffs instead of re-pinning the same stale SHA, so a blob-mismatch refusal can't loop forever. - source="main" now diffs against the last catalog a maintainer actually SIGNED (walking catalog.json's git history until a version verifies against the current .sig), not against itself. - Replaced the theatre-only test_no_acknowledge_all_function_exists (only asserted no function was *named* acknowledge_all) with a test that also exercises the real gate. Added can_sign/sign_precondition coverage for the empty-diff, blocking-risk, and ref-resolution seams -- each verified to fail when its guard is removed. Finding 5 -- the catalog key and release key were the same CI-resident key: - scripts/sign_checksums.py gets its own RELEASE_PUBKEYS (separate from bcc_core.CATALOG_PUBKEYS) and a verify_checksums_against_any() helper. - release.yml's signing-smoke-test now verifies RELEASE_SIGNING_KEY against RELEASE_PUBKEYS only -- it no longer imports bcc_core/CATALOG_PUBKEYS at all, so this workflow can never compare a CI secret against the catalog's root of trust. - catalog_console.py: keygen/show-seed-b64 gain --release, with separate keychain/file storage per key kind. show-seed-b64 refuses to run without --release, so the catalog seed can't be exported to a CI secret by habit. - README documents both keys' trust properties and the asymmetry: a CI compromise burns the release key, never the catalog key. The maintainer must rotate the catalog key (it was CI-resident, so treat it as burned for catalog use) and generate a fresh release key -- see the PR description for the exact steps. No key is generated or committed here.	2026-07-12 21:25:34 -04:00
the_og	6fce19cc67	ci: gate the catalog signature, smoke-test the release key (#61, #63) ... Two gaps closed now that a real key exists. 1. CI 'Catalog signature' job (the #61 gate): every push/PR verifies data/catalog.json against data/catalog.json.sig using the public key in bcc_core, and runs validate_catalog. The threat model here is not an outsider pushing to the repo -- it is merging a friendly-looking PR without really reading it. A contributor can change catalog.json but cannot produce a matching signature, so a blindly-merged PR now lands as a red build within a minute instead of quietly riding into the next release. Public-key only; no secret involved. 2. release.yml 'Signing key smoke test' (workflow_dispatch only): the Publish job is gated on a tag, so a manual run never exercised signing -- a wrong or missing RELEASE_SIGNING_KEY would first surface during a real release. This signs a throwaway manifest with the secret and verifies it against the public key compiled into bcc_core, proving the two halves of the keypair actually match. Publishes nothing.	2026-07-12 18:30:30 -04:00
the_og	37b3c8f5d0	catalog: trust the real signing key ... Adds the Ed25519 public key generated by the Catalog Console (#62), replacing the b"\x00"*32 placeholder, and imports base64 (the key line referenced it without the import, so bcc_core failed to load at all). Verified end to end against the signature the Console pushed in b08cf21: signature verifies, catalog validates clean, resolve_catalog accepts the bundled copy (19 servers), and a single-byte tamper is rejected.	2026-07-12 18:25:49 -04:00
Cowork Supervisor	b08cf2112b	chore: sign data/catalog.json (Catalog Console, #62) ... Payload and detached Ed25519 signature land together so main is never red between a catalog merge and its signature.	2026-07-12 18:22:41 -04:00
the_og	80761a1f17	Merge PR #66: Catalog Console — maintainer review + signing tool (#62) ... Maintainer-only PySide6 tool: semantic per-entry diff of data/catalog.json, blocking risk predicates (non-empty env values, command allowlist, non-ASCII homoglyphs, unpinned packages, URL domain changes), automatic off-thread registry lookups (publisher/age/downloads/near-neighbour), acknowledge-gated signing with a pinned git blob SHA (refuses to sign bytes that changed since review), and payload+signature emitted in a single commit. Never shipped to users — excluded from bcc.spec, with a test asserting it.	2026-07-12 18:04:53 -04:00
BCC Agent	d6fc6845c4	fix(catalog-console): run registry lookup automatically, not on click (#62) ... Review feedback: making the registry lookup an on-demand 'Check registry' button was a deviation from the design intent, not a style choice. The registry lookup is the one check a human reviewer genuinely cannot do by eye -- it's what caught firecrawl-mcp's unrelated npm publisher in the seed data. Gating it behind a button makes it optional, and an optional check is the one a tired maintainer skips at 11pm -- exactly the failure mode this tool exists to defend against. The friction belongs on approval, never on information. EntryCard now kicks off its registry lookup automatically at construction time (i.e. as soon as _render_cards() builds the cards for a loaded review), one RegistryLookupWorker (QThread) per changed entry, all starting concurrently as the cards are built. Nothing about the lookup's pure logic changed -- catalog_review.lookup_registry_info was already fail-soft (RegistryInfo(available=False) on any fetch problem, never an exception) and can_sign() never depended on registry state, so a dead registry still cannot gate review or signing. Renamed the button 'Check registry' -> 'Re-check' and kept it wired to the same _run_registry_lookup(), for manually retrying a failed/unavailable lookup. Label copy now reads loading... while a lookup is in flight (was 'not checked yet.' / 'checking...'), matching the loading -> result | unavailable per-entry states. No change to acknowledge-gating or the TOCTOU blob-SHA pin in catalog_review.py. ruff check/format clean; full suite still 321 passed, 1 pre-existing unrelated skip -- catalog_review.py (the tested pure-logic module) is untouched, only catalog_console.py's GUI wiring moved from button-triggered to auto-triggered.	2026-07-12 18:04:28 -04:00
BCC Agent	f0d0ab7a08	feat: Catalog Console -- maintainer-only review + signing tool (#62) ... Adds a separate PySide6 tool (catalog_console.py) that reviews proposed changes to data/catalog.json and signs the approved result. Never shipped to users, never in the release bundle -- maintainer runs it from source. Pure, GUI-free logic lives in a new catalog_review.py (kept out of both the GUI and bcc_core.py to avoid merge conflicts on the latter): - diff_catalogs(old, new) -> list[EntryChange]: semantic (per-entry) diff, not a text diff, with per-field before/after values. - Six independent risk predicates, each unit-tested: non-empty env_required value, command outside bcc_core.CATALOG_ALLOWED_COMMANDS (imported, not redefined), non-ASCII code points in id/command/args (rendered with escapes -- homoglyph/RTL-override defence), unpinned npm/docker package references, URL domain changes (lookalike-domain swap defence), brand-new entries flagged for extra scrutiny. - ReviewSession + can_sign(): the Sign button stays disabled until every changed entry is individually acknowledged -- no "acknowledge all" shortcut exists, and a comment in the code says never to add one. - TOCTOU fix (adversarial review on #62): the git blob SHA of data/catalog.json is pinned when review begins; can_sign() refuses to sign if the current blob differs, forcing a re-review. The Console re-fetches the blob SHA immediately before signing and enforces this. - catalog_signing_message() imports bcc_core's domain-separation prefix (_CATALOG_SIG_DOMAIN) rather than retyping it, so the Console's signatures and bcc_core.verify_catalog_signature can't drift apart -- proven by a round-trip test (sign here, verify via bcc_core). - encrypt_private_key/decrypt_private_key: the signing key is never stored plaintext (scrypt + AES-256-GCM at rest, OS keychain via the optional keyring package if available, else an encrypted file under $HOME outside the repo). - Registry lookup (lookup_registry_info + injected Fetcher): the network call is kept out of this module for offline testability; catalog_console.py supplies npm/PyPI HTTP fetchers. Fails soft -- network down means "unavailable", never a block on review. near_neighbor_ids() flags edit-distance <=2 typosquat candidates against existing catalog ids. catalog_console.py wires the above into a Qt GUI: Load (open PRs touching data/catalog.json via the Gitea REST API, or main) -> Review (one EntryCard per changed entry, command/args rendered visually dominant, risk findings colour-coded, per-card registry-lookup button running off the UI thread like bcc.py's ConnTester/SpawnTester) -> Sign (re-checks the pinned blob SHA, prompts for the key passphrase, writes data/catalog.json + data/catalog.json.sig and commits+pushes BOTH in a single commit -- so main is never red between a catalog merge and its signature). Every attacker-controlled string renders through a plain_label() helper that both escapes HTML and forces Qt.PlainText, so a script/image payload in a description/notes/URL can't render as markup. Also provides keygen (generates + stores an encrypted keypair, prints the base64 public key) and show-seed-b64 (prints the base64 private seed for the RELEASE_SIGNING_KEY CI secret) CLI subcommands. Excluded from the release bundle: bcc.spec's Analysis() only ever starts from bcc.py, and tests/test_catalog_console_packaging.py asserts neither new file is named anywhere in bcc.spec and that bcc.py never imports either module. Tests: 67 new (62 in test_catalog_review.py, 5 in test_catalog_console_packaging.py) covering diff_catalogs, every risk predicate individually, the acknowledge-gating + TOCTOU can_sign() logic, the sign/verify round-trip against bcc_core, key encryption (including wrong-passphrase and corrupted-blob rejection), edit-distance/near-neighbour matching, and registry-lookup fail-soft behaviour. Full suite: 321 passed, 1 pre-existing unrelated skip. ruff check and ruff format --check both clean. catalog_console.py (Qt/GUI) could not be executed in the sandbox this was developed in (no system EGL/GL libraries available for PySide6) -- it was syntax-checked (py_compile) and lint/format-checked but not smoke-tested; see PR body for what AJ should verify. Closes #62	2026-07-12 17:57:00 -04:00
the_og	3841106630	Merge pull request 'feat: MCP server catalog core -- signed, validated, resolvable (#10, #61)' (#65) from feat/10-catalog-core into main	2026-07-12 17:55:49 -04:00
the_og	e3581b6e8b	Merge branch 'main' into feat/10-catalog-core	2026-07-12 17:42:12 -04:00
the_og	672d78f903	Merge PR #64: signed SHA256SUMS for releases (#63) ... Publish SHA-256 checksums for every release artifact and sign them with a domain-separated Ed25519 signature. Skips signing (loudly) if the key secret is absent rather than failing the release. README documents verification and states the limit plainly: this proves the file is the one we published; it does not remove Gatekeeper/SmartScreen warnings.	2026-07-12 17:42:09 -04:00
the_og	88e93edc6c	catalog: pin exact package versions, drop firecrawl, add last_release ... - Pin every basic-tier entry to an exact published version (npm @x.y.z, uvx @x.y.z, docker :tag). Unpinned npx -y <pkg> means a package compromised AFTER we ship auto-upgrades into every user; a pin bounds supply-chain compromise to versions we actually reviewed. - Drop firecrawl from the seed (19 entries). npm publish rights are held solely by hello_sideguide/sideguide.dev, which has no visible relationship to firecrawl.dev, while the package is presented as official. Publisher identity we cannot tie to the vendor is exactly what this catalog must not execute on a user's machine. Retained in the research pool pending confirmation. - postgres: ship --access-mode=restricted, not unrestricted. A curated catalog must not default to handing an LLM write access to your DB. - Add last_release (ISO date, from the live registry) so the UI can show freshness; postgres-mcp and mcp-obsidian are both ~14mo stale.	2026-07-12 17:35:48 -04:00
Cowork Agent	48904c7787	feat: MCP server catalog core -- signed, validated, resolvable (#10, #61) ... Phase 1 of the MCP server catalog: pure, GUI-free core functions plus the seed data/catalog.json (20 servers). No GUI wiring in this PR -- bcc.py is untouched; a follow-up PR adds the picker dialog. - load_catalog(): strict json.loads ONLY. The lenient repair pipeline (repair_json_text / parse_pasted_json*) is never used on catalog bytes, by design and by comment, so a signature always authenticates exactly what gets parsed. - validate_catalog(): rejects the whole file (not per-entry) on: bad schema/version types, missing tier-appropriate fields (basic needs config.command+args, link-only needs docs_url and no config), a command allowlist (npx/uvx/docker/node/python/python3 only), -e/--eval/-c denial for node/python, --privileged and root/$HOME volume-mount denial for docker, non-empty env_required values (hard rejection -- secrets never ship in the catalog), secret-looking args (reuses _TOKEN_PREFIXES/_is_secret_value rather than reimplementing), non-https URL fields, and non-ASCII code points in id/command/args (homoglyph defence). - verify_catalog_signature(): Ed25519 via the cryptography package, domain-separated message (the literal prefix "bcc-catalog-v1|" + raw bytes), accepts a match against any key in CATALOG_PUBKEYS (rotation-ready), never raises. - resolve_catalog(): picks the highest version among bundled/cached/remote candidates that EACH independently pass verify + validate -- the bundled catalog gets no implicit trust, closing the hole where an unsigned payload merged to main would win on being local. Anti-rollback (never regress below the best verified candidate already in hand) and anti-freeze (reject a jump of more than 1000 versions) built in. - catalog_entry_to_paste_json() / config_has_unfilled_placeholders(): small pure helpers the future GUI dialog will use to feed a catalog pick into the existing paste-import path and to gate Save on unfilled placeholder tokens. data/catalog.json: the provided 20-server seed, with a signed_at field added at the top level (lives inside the signed payload once real signing lands in #62). Wired into bcc.spec's PyInstaller datas so it bundles into the frozen app. Security requirements from the issue, and where they landed: - Catalog bytes never touch the lenient JSON repair path -- enforced by load_catalog()'s strict json.loads and a comment warning against wiring it in later. - env_required values are a hard rejection when non-empty, not a warning. - Secret-looking args are rejected at validation time, reusing the existing secret-detection helpers instead of duplicating them. - Non-ASCII id/command/args rejected (typosquat/homoglyph defence). - URL fields restricted to https://. - Ed25519 signature verification is domain-separated and never raises. - The bundled catalog is verified at runtime exactly like remote/cached -- no implicit trust for being local. - Anti-rollback and anti-freeze bounds on resolve_catalog's version comparison. Tests: 42 new tests added to tests/test_core.py (full suite: 239 passed, 1 pre-existing unrelated skip). ruff check and ruff format --check both clean.	2026-07-12 17:32:50 -04:00
BCC Agent	cd38fd0c78	Sign release checksums with Ed25519 (#63) ... Publish SHA256SUMS for every release archive and sign it with a detached Ed25519 signature (SHA256SUMS.sig), since paid code signing (macOS Developer ID, Windows Authenticode) and Sigstore keyless (needs a Fulcio-trusted OIDC issuer; self-hosted Gitea isn't one) are both out of budget/scope. - scripts/sign_checksums.py: dependency-light (cryptography only) helper to hash a directory of files into a sha256sum(1)-compatible SHA256SUMS manifest, sign it (domain-separated: b"bcc-release-v1|" + raw manifest bytes), and verify a signature. CLI has generate/ sign/verify subcommands; verify doubles as the check path. - tests/test_checksums.py: 15 unit + CLI-subprocess tests covering hashing, manifest formatting, sign/verify roundtrip, tamper detection, wrong-key rejection, domain-separation, and the no-key-provided failure path (must error, never write an empty/ bogus .sig). - .github/workflows/release.yml: Publish Release job now checks out the repo, flattens build artifacts, generates SHA256SUMS, and signs it from the RELEASE_SIGNING_KEY secret (base64 raw Ed25519 seed) if present. If the secret is absent, the release still publishes with a loud ::warning:: and no .sig — it never fails the release or publishes a bogus signature. - README.md: new 'Verifying your download' section with the (still placeholder) public key, sha256sum -c / Get-FileHash commands, and an explicit statement that this does not remove Gatekeeper/ SmartScreen warnings. - requirements-dev.txt / ci.yml: add cryptography as a dev/test dependency for the new script and its tests. Touches no files from bcc_core.py / tests/test_core.py / pyproject.toml / bcc.spec to avoid colliding with concurrent work on those files.	2026-07-12 17:30:09 -04:00
the_og	e6b60e94e7	Merge pull request 'release: v1.3.0 — named server sets, project config discovery, schema lint, UX polish' (#60) from release/v1.3.0 into main v1.3.0	2026-07-12 14:03:50 -04:00
Cowork SupervisorandClaude Fable 5	4afe21666d	release: bump version to 1.3.0 ... Named server sets (#52), project .mcp.json discovery (#53), schema lint (#54), Ctrl+S + enable/disable-all (#55). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-12 14:02:38 -04:00
the_og	06e74d4d2c	Merge pull request 'feat: Ctrl+S save shortcut + enable/disable-all actions (#55)' (#59) from feat/55-ux-polish into main	2026-07-12 14:02:23 -04:00
Cowork Supervisor	f92b851127	Merge remote-tracking branch 'origin/main' into feat/55-ux-polish	2026-07-12 14:00:56 -04:00
the_og	47c95ac006	Merge pull request 'feat: named server sets — save/apply the Active/Disabled split (#52)' (#56) from feat/52-server-sets into main	2026-07-12 14:00:19 -04:00
the_og	6b22ad26f0	Merge pull request 'feat: structural schema lint for server definitions (#54)' (#58) from feat/54-schema-lint into main	2026-07-12 14:00:12 -04:00
the_og	874948506c	Merge pull request 'feat: discover Claude Code project .mcp.json configs as profiles (#53)' (#57) from feat/53-project-mcp-discovery into main	2026-07-12 13:58:52 -04:00
Cowork SupervisorandClaude Fable 5	ac2e73e9d7	feat: named server sets — save/apply the Active/Disabled split (#52) ... Sets live in the config under _bccServerSets (bcc-owned, ignored by Claude, travels with the file). Apply enables exactly the set's members and parks the rest; vanished members are reported, not fatal. GUI row: set combo + Apply + Save set… + delete. Closes #52 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-12 13:55:36 -04:00