[BUG] apm install rewrites apm.lock.yaml on every run for unchanged LSP dependencies

[paul-ww]

Describe the bug

apm install rewrites apm.lock.yaml on every run when a project has unchanged LSP dependencies. The diff changes only generated_at.

This is distinct from #1702. The smallest repro does not require local .apm/instructions or local .apm/skills. A single unchanged LSP dependency is enough.

In my repro, the trigger is the Astral marketplace plugin because it contributes lsp_servers / lsp_configs state.

To Reproduce

I reproduced this using APM 0.24.0 through uv run apm.

tmpdir="$(mktemp -d)"
mkdir -p "$tmpdir"

cat > "$tmpdir/apm.yml" <<'YAML'
name: apm-min-astral-only
version: 1.0.0

targets:
  - claude
  - copilot

includes: auto

dependencies:
  apm:
    - astral-sh/claude-code-plugins/plugins/astral#f3ce88a7ba830f53afd6d944c1d0278ed318e142
  mcp: []
YAML

UV_PROJECT=/path/to/repo-with-apm-installed uv --directory "$tmpdir" run --no-sync apm install
cp "$tmpdir/apm.lock.yaml" "$tmpdir/first.lock"
UV_PROJECT=/path/to/repo-with-apm-installed uv --directory "$tmpdir" run --no-sync apm install
diff -u "$tmpdir/first.lock" "$tmpdir/apm.lock.yaml"

Expected behavior

Second run should be a no-op and should not rewrite apm.lock.yaml.

Actual behavior

Second run rewrites only generated_at. Example diff:

@@ -1,5 +1,5 @@
 lockfile_version: '1'
-generated_at: '2026-07-09T07:35:45.785556+00:00'
+generated_at: '2026-07-09T07:35:47.010367+00:00'
 apm_version: 0.24.0
 dependencies:
 - repo_url: astral-sh/claude-code-plugins

Example install output tail on the second run:

[i] Targets: claude, copilot  (source: apm.yml)
  [+] github.com/astral-sh/claude-code-plugins/plugins/astral#f3ce88a7... @f3ce88a7 (cached)
  |-- Skill integrated -> .agents/skills/, .claude/skills/
  |-- 3 skill(s) integrated -> .agents/skills/, .claude/skills/

[*] Installed 1 APM dependency in 0.1s.

Root cause

The main lockfile builder preserves existing MCP state and local .apm state before semantic comparison, but it does not preserve existing LSP state. On a second unchanged install, the in-memory lockfile temporarily drops lsp_servers and lsp_configs, fails the semantic no-op check, and rewrites apm.lock.yaml.

A matching carry-forward for LSP state fixes the problem locally.

Validation

I validated a local patch that preserves existing lsp_servers and lsp_configs before _write_if_changed(...):

• the minimal Astral-only repro stopped rewriting the lockfile
• a real project that previously reproduced the issue stopped changing apm.lock.yaml on repeated uv run apm install --frozen

Environment

• OS: Linux
• Python: 3.14.5 in the reproducing environment
• APM: 0.24.0 (58b683d48)

I also prepared a small patch and regression test for this and can send a PR referencing this issue.

[github-actions]

Triage Panel Verdict

Issue: [BUG] apm install rewrites apm.lock.yaml on every run for unchanged LSP dependencies
Reporter: @paul-ww -- thank you for the precise repro, root cause, and offered patch.

Summary

apm install unconditionally rewrites apm.lock.yaml on every invocation when the project has LSP dependencies (e.g., the Astral marketplace plugin contributing lsp_servers/lsp_configs). The diff is always only generated_at. Root cause: the lockfile builder carries forward existing MCP state and local .apm state before the semantic no-op check, but does not carry forward existing LSP state -- causing the in-memory lockfile to temporarily drop lsp_servers/lsp_configs, failing the equality check and triggering a rewrite.

Panel Findings

DevX UX Expert -- Accept: Spurious lockfile rewrites pollute version-controlled diffs and defeat the "second install is a no-op" contract that users and CI pipelines rely on. Any workflow that checks git diff after apm install will see noise on every run. Particularly annoying when the generated_at timestamp is the only difference.

Supply Chain Security Expert -- Accept: When every apm install produces a lockfile diff, reviewers learn to ignore lockfile changes -- reducing the security value of lockfile diffs in code review. The fix restores the signal: a lockfile change means something actually changed.

Python Architect -- Accept: The fix is straightforward: apply the same carry-forward logic used for MCP state to LSP state (lsp_servers/lsp_configs) before the _write_if_changed(...) comparison. The reporter has already identified and validated the patch. Good candidate for a community PR.

APM CEO (Arbiter) -- Accept: Idempotent installs are a basic correctness property. The reporter has done the legwork. Invite them to open a PR with their patch and regression test.

Decision

Field	Value
Classification	Bug -- lockfile idempotency
Severity	Low (cosmetic; only timestamp changes)
Proposed labels	type/bug, theme/portability, area/lockfile, priority/low, status/accepted, status/triaged, help wanted
Milestone	Deferred to maintainer
Next action	Carry forward existing lsp_servers/lsp_configs before the semantic no-op check, mirroring the existing MCP carry-forward; reporter has a validated patch ready -- invite PR

---

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 · 128 AIC · ⌖ 16.9 AIC · ⊞ 9.2K · ◷