~/work/app/.mcp.json and ~/personal/app/.mcp.json both render as "Project: app". Paths are deduped correctly, so both profiles exist — they're just indistinguishable in the picker. Pick the wrong one and you edit (and back up, and write) the wrong repo's config.
Common in practice: api, web, app, server, client as repo directory names.
Suggested fix
Disambiguate only when needed, so the common case stays readable:
Detect duplicate basenames within the discovered set and, for those only, extend the label with the parent directory (Project: work/app vs Project: personal/app) — widening further if still ambiguous.
Put the full path in the combo item's tooltip regardless, so it's always verifiable.
Also worth tightening while in here
discover_project_configs's docstring says it looks for "a standalone file with a top-level mcpServers object", but the code only checks mcp_path.is_file(). A .mcp.json that's a JSON array or garbage still becomes a profile and only fails when opened. Either check for a readable dict (cheap — these files are tiny) or correct the docstring.
Tests
Two projects keys with the same basename produce two distinct labels; a single project keeps the plain Project: <name> form.
## What
`discover_project_configs()` labels every project profile by basename only:
```python
Profile(label=f"Project: {Path(key).name}", path=mcp_path, config_exists=True)
```
`~/work/app/.mcp.json` and `~/personal/app/.mcp.json` both render as **"Project: app"**. Paths are deduped correctly, so both profiles exist — they're just indistinguishable in the picker. Pick the wrong one and you edit (and back up, and write) the wrong repo's config.
Common in practice: `api`, `web`, `app`, `server`, `client` as repo directory names.
## Suggested fix
Disambiguate only when needed, so the common case stays readable:
- Detect duplicate basenames within the discovered set and, for those only, extend the label with the parent directory (`Project: work/app` vs `Project: personal/app`) — widening further if still ambiguous.
- Put the full path in the combo item's tooltip regardless, so it's always verifiable.
## Also worth tightening while in here
`discover_project_configs`'s docstring says it looks for "a standalone file with a top-level `mcpServers` object", but the code only checks `mcp_path.is_file()`. A `.mcp.json` that's a JSON array or garbage still becomes a profile and only fails when opened. Either check for a readable dict (cheap — these files are tiny) or correct the docstring.
## Tests
Two `projects` keys with the same basename produce two distinct labels; a single project keeps the plain `Project: <name>` form.
the_og
added the P2 label 2026-07-20 12:07:17 -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
discover_project_configs()labels every project profile by basename only:~/work/app/.mcp.jsonand~/personal/app/.mcp.jsonboth render as "Project: app". Paths are deduped correctly, so both profiles exist — they're just indistinguishable in the picker. Pick the wrong one and you edit (and back up, and write) the wrong repo's config.Common in practice:
api,web,app,server,clientas repo directory names.Suggested fix
Disambiguate only when needed, so the common case stays readable:
Project: work/appvsProject: personal/app) — widening further if still ambiguous.Also worth tightening while in here
discover_project_configs's docstring says it looks for "a standalone file with a top-levelmcpServersobject", but the code only checksmcp_path.is_file(). A.mcp.jsonthat's a JSON array or garbage still becomes a profile and only fails when opened. Either check for a readable dict (cheap — these files are tiny) or correct the docstring.Tests
Two
projectskeys with the same basename produce two distinct labels; a single project keeps the plainProject: <name>form.the_og referenced this issue2026-08-03 22:41:03 -04:00