apm: lockFileMaintenance deletes apm.lock.yaml, which drops APM's ownership of committed files and MCP entries

[salpers]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

44.131.3

Please tell us more about your question or problem

Minimal reproduction: https://github.com/salpers/renovate-apm-lock-maintenance-repro

For lockFileMaintenance, the apm manager deletes apm.lock.yaml and then runs apm install (artifacts.ts#L44-L58). APM's lockfile isn't only a version pin. It also records which deployed files and native MCP config entries APM manages. APM projects commit the files apm install deploys (.github/, .claude/, .mcp.json, ...). With the lock gone, apm install finds those files already on disk and can't tell them apart from files a user wrote by hand, so it won't claim them. The resulting maintenance PR:

• drops the MCP ownership records (mcp_target_servers: {} and no kind: uri deployments)
• drops 7 of the deployed files from the lock's deployed_files in the repro
• makes apm audit --ci fail with Drift detected: 7 file(s) ... unrecorded

Running apm install again doesn't restore the records. On our repo, every weekly lock file maintenance PR had exactly this diff. The APM maintainers looked at it in microsoft/apm#3090. They don't want APM to rebuild ownership from matching file contents, because an identical file could have been written by hand. They'd rather the integration keep the existing lockfile.

Results from the repro's committed state with apm 0.32.0 (the lock pins microsoft/apm-sample-package one commit behind):

Command	apm-sample-package	transitive dep	MCP records	apm audit --ci
rm apm.lock.yaml && apm install (today)	bumped	bumped	0 of 4	fails
apm update --yes	bumped	bumped	4 of 4	passes
apm install --refresh	not bumped	bumped	4 of 4	passes

Suggested fix: when isLockFileMaintenance is set, keep the lockfile and run apm update --yes instead of apm install. apm update is the <tool> update command that the adding-a-package-manager guide recommends over delete-and-install. It re-resolves every dependency in apm.yml, transitive ones included, to the latest ref the manifest allows. It doesn't touch the manifest, it redeploys changed files, and it reconciles MCP servers. It has been available since APM 0.23.0. The other path (apm install after a manifest bump) keeps the lockfile and isn't affected.

If that direction works for you, I'm happy to open the PR (artifacts.ts, spec and readme).

Workaround until then, for repos whose apm dependencies are all pinned exactly (so maintenance has nothing to refresh): "apm": { "lockFileMaintenance": { "enabled": false } }.

Logs (if relevant)

apm install output after the lockfile was deleted

[i] Targets: claude, codex, copilot, cursor  (source: apm.yml)
  [+] microsoft/apm-sample-package #main @fb285168
  [+] github.com/github/awesome-copilot/skills/review-and-refactor #default @143a3d97
  |-- 2 prompts adopted -> .github/prompts/
  |-- 3 agents adopted -> 3 targets
  |-- 3 rule(s) adopted -> 3 targets
  |-- 1 skill(s) integrated -> .agents/skills/, .claude/skills/
  |-- (files unchanged)
+- MCP Servers (1)
|  [+] shadcn (already configured)
[*] All servers up to date
  [!] 7 files skipped -- local files exist, not managed by APM
    Use 'apm install --force' to overwrite

[Dani-8]

Hi @salpers,

Diagnosis & Proposed Solution

Your diagnosis is correct. APM's update strategy relies on having an up-to-date lockfile with metadata about the state of installed packages, including MCP ownerships and file hashes of all deployed files.

Deleting apm.lock.yaml before installing new versions of a package removes that critical context needed for apm install to behave correctly.

Using apm update --yes as part of your lockFileMaintenance matches the recommended approach for package manager artifact updates of using renovate (and similar tools).

It will update all locked/transitive dependencies that have changed while keeping APM-managed state.

Suggested Next Steps

1. Open a PR: You should open a Pull Request (against artifacts.ts) and update the relevant unit specs and documentation.

2. Implementation Summary: In artifacts.ts, you'll want to check for config.isLockFileMaintenance (or whatever lock file maintenance flag is used).

• If true, keep apm.lock.yaml and update all locked/transitive dependencies by running apm update --yes.

• Make sure to leave the fallback/default behavior for normal manifest bumps (apm install) untouched.