Bug: `MCPIntegrator.update_lockfile` uses `Path.cwd()` at `--global` scope, writing MCP audit entries to the wrong lockfile

[sergio-sisternes-epam]

Summary

MCPIntegrator.update_lockfile() defaults lock_path to get_lockfile_path(Path.cwd()) when the caller does not pass an explicit path. At --global scope (apm install -g), the lockfile should be written to ~/.apm/apm.lock.yaml, but callers in install.py do not pass the scope-resolved lockfile path to update_lockfile. This causes MCP server audit entries to be written to the project-local lockfile instead of the user-scope lockfile.

Reproduction

1. cd /tmp/some-project && apm init
2. apm install -g some-org/some-mcp-package
3. Observe that ./apm.lock.yaml (project) gets MCP entries instead of ~/.apm/apm.lock.yaml.

Expected Behavior

At --global scope, update_lockfile should persist MCP server entries in the user-scope lockfile (~/.apm/apm.lock.yaml).

Relevant Code

• src/apm_cli/integration/mcp_integrator.py, update_lockfile() method (lines ~639-673)
• src/apm_cli/commands/install.py or src/apm_cli/install/ callers

Context

Discovered during review of #638 (apm install --global MCP scope filtering). The scope-filtering fix in #638 correctly routes MCP installation to global-capable runtimes, but the lockfile path was out of scope for that PR.

Labels

bug

[github-actions]

Triage decision

accept

Proposed labels

theme/governance
area/lockfile
area/cli
type/bug
status/accepted
priority/high

Milestone

0.9.4

Suggested next action

Pass the scope-resolved lockfile path (~/.apm/apm.lock.yaml for --global) explicitly to MCPIntegrator.update_lockfile() in the install caller.

Suggested issue comment

Thanks for the precise bug report and code pointers.

The root cause is confirmed: `update_lockfile()` defaults to `Path.cwd()` when no path is passed, but callers in the install pipeline do not forward the scope-resolved lockfile path at `--global` scope. MCP server audit entries for a global install silently land in the project-local lockfile instead of `~/.apm/apm.lock.yaml`.

This is `priority/high` because it corrupts the audit trail -- the global lockfile is the source of truth for globally installed MCP servers, and missing entries there mean `apm` cannot correctly reason about what is installed at global scope.

Fix: thread the scope-resolved lockfile path from the install caller through to `MCPIntegrator.update_lockfile()`. The callers already have scope awareness from #638 -- this is a one-step extension to also forward the correct path.

Accepting for 0.9.4.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

Clear correctness bug with a precise reproduction path. When using apm install -g, MCP server entries land in the wrong lockfile (project-local vs. user-global). This is a silent data-integrity failure: the user has no visual indication that the global lockfile is missing entries. The fix is well-identified and the scope is narrow.

Supply Chain Security Expert -- Risk-Surface Reviewer

Touches area/lockfile and area/mcp-config. A lockfile written to the wrong path means the global MCP audit trail is incomplete -- a governance surface. theme/governance applies: lockfile integrity is part of APM's governance/audit story. The bug fix improves audit integrity. No credential or signing exposure.

OSS Growth Hacker -- Contributor-Tone Reviewer

Not activated -- sergio-sisternes-epam is a COLLABORATOR with many prior interactions; standard tone is appropriate.

Python Architect -- Architecture Reviewer

Not activated -- the fix is a narrow call-site change: pass the scope-resolved lockfile path to update_lockfile(). No cross-cutting design decision required; the scope-resolution logic already exists from #638.

Doc Writer -- Documentation Reviewer

Not activated -- a bug fix for an incorrect lockfile write path has no user-facing documentation implications; no new docs surfaces are added or changed.

APM CEO -- Triage Arbiter

Clear accept at priority/high. Silent audit-trail corruption at global scope is a meaningful data integrity bug. Fits the 0.9.4 patch cycle. theme/governance is correct: this is about ensuring the lockfile accurately reflects global install state, which is the foundation of APM's governance/audit story.

{
  "decision": "accept",
  "decision_detail": "",
  "theme": "theme/governance",
  "areas": ["area/lockfile", "area/cli"],
  "type": "type/bug",
  "status": "status/accepted",
  "priority": "priority/high",
  "preserved_labels": [],
  "milestone": "0.9.4",
  "next_action": "Pass the scope-resolved lockfile path (~/.apm/apm.lock.yaml for --global) explicitly to MCPIntegrator.update_lockfile() in the install caller.",
  "comment_markdown": "Thanks for the precise bug report and code pointers.\n\nThe root cause is confirmed: `update_lockfile()` defaults to `Path.cwd()` when no path is passed, but callers do not forward the scope-resolved lockfile path at `--global` scope. MCP server audit entries for a global install silently land in the project-local lockfile instead of `~/.apm/apm.lock.yaml`.\n\nThis is `priority/high` because it corrupts the audit trail -- the global lockfile is the source of truth for globally installed MCP servers. Fix: thread the scope-resolved lockfile path from the install caller through to `MCPIntegrator.update_lockfile()`. Accepting for 0.9.4."
}

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel · ● 1.6M · ◷