Description
The project alias cache is stored globally in ~/.sentry-cli-next/config.json without any workspace context. When switching between monorepos or using multiple terminals in different workspaces, aliases from one workspace overwrite another's. This can cause issue get to silently resolve to the wrong project.
Root Cause
setProjectAliases() in src/lib/config.ts writes to a global config file without any workspace identifier:
// src/lib/config.ts:387-396
export async function setProjectAliases(
aliases: Record<string, ProjectAliasEntry>
): Promise<void> {
const config = await readConfig();
config.projectAliases = {
aliases,
cachedAt: Date.now(),
};
await writeConfig(config); // Global file, no workspace context
}
Reproduction
- Open two terminals in different monorepo workspaces
- In Terminal A (
~/monorepo-a/): run sentry issue list → aliases cached (e.g., e = electron)
- In Terminal B (
~/monorepo-b/): run sentry issue list → aliases overwritten (e.g., e = express)
- In Terminal A: run
sentry issue get e-A3 → resolves using Terminal B's aliases (wrong project!)
Expected Behavior
Aliases should be scoped to the workspace where issue list was run. Options:
- Store workspace path (or hash) alongside aliases
- Validate that current workspace matches cached workspace before using aliases
- Fall back to explicit resolution when workspace mismatch detected
Severity
Medium - Causes confusion in multi-workspace setups, but the error is usually apparent (wrong project name or 404) and re-running issue list fixes it.
References
Suggested Fix
Store workspace context with aliases and validate before use:
config.projectAliases = {
aliases,
cachedAt: Date.now(),
workspacePath: cwd, // Add workspace context
};
// In getProjectByAlias, validate workspace matches or ignore stale cache
Description
The project alias cache is stored globally in
~/.sentry-cli-next/config.jsonwithout any workspace context. When switching between monorepos or using multiple terminals in different workspaces, aliases from one workspace overwrite another's. This can causeissue getto silently resolve to the wrong project.Root Cause
setProjectAliases()insrc/lib/config.tswrites to a global config file without any workspace identifier:Reproduction
~/monorepo-a/): runsentry issue list→ aliases cached (e.g.,e= electron)~/monorepo-b/): runsentry issue list→ aliases overwritten (e.g.,e= express)sentry issue get e-A3→ resolves using Terminal B's aliases (wrong project!)Expected Behavior
Aliases should be scoped to the workspace where
issue listwas run. Options:Severity
Medium - Causes confusion in multi-workspace setups, but the error is usually apparent (wrong project name or 404) and re-running
issue listfixes it.References
Suggested Fix
Store workspace context with aliases and validate before use: