Disable the PHP LSP Claude Code plugin (php-lsp) — per-agent LSP server strain, low value

Operator confirmed "yea disable the lsp thing" (2026-07-04). Verified current state: `~/.claude/settings.json` line 36 = `"php-lsp@claude-plugins-official": false` — already applied inline by flower-ops on 2026-07-04 00:53 at the operator's earlier direction. Confirmed the disable is taking effect: the 5 workers I spawned this session (1124–1128) added ZERO new php-lsp servers; the process count held at ~3 = the pre-disable standing daemons (ops/refine + one residual), which self-clear on their next reset/respawn. Disable-vs-uninstall: operator chose DISABLE (reversible, sufficient); uninstall deferred as a later option if it's confirmed unmissed. DoD met → marking complete. No dispatch needed (work already applied).

APPLIED 2026-07-04 (operator-directed, inline — not dispatched): flipped `"php-lsp@claude-plugins-official"` from true→false in ~/.claude/settings.json (confirmed line 36 = false). Timing: operator confirmed all interactive/worker sessions were off, only the 3 standing daemons (ops 1054 / orchestrator / refine) live. The raw settings Edit succeeded with no classifier block (a plugin toggle is not a permission bypass). Effect: new + resumed sessions spawn no php-lsp server; the 3 daemons keep their existing LSP server until their next reset/respawn (which re-reads settings) — they self-clear as they cycle, or can be killed directly. REMAINING (this brief): (1) verify a freshly spawned/resumed session shows no php-lsp server; (2) operator decision — disable (done) vs full uninstall (`/plugin` remove).

## Objective Disable the global `php-lsp@claude-plugins-official` Claude Code plugin. It spawns ONE PHP language-server process per agent session — meaningful aggregate resource strain when many flower daemons + workers run concurrently — for a benefit the operator judges low (noise > value). ## Problem / rationale - `php-lsp@claude-plugins-official` is enabled **globally** in `~/.claude/settings.json` (`enabledPlugins["php-lsp@claude-plugins-official"] = true`); it is NOT configured at the flower project level, so it attaches to every Claude Code session on this machine. - It runs a language server **per agent** — evidence 2026-07-04: **7 LSP-ish node processes** observed concurrently (~one per live agent session: standing daemons orchestrator/ops/refine + spawned workers + interactive). Idle they are light (~0.2% RAM each, ~0% CPU), but each PHP LSP can balloon to hundreds of MB while indexing the large Laravel trees here, and the flower workflow routinely runs many concurrent agents → N servers × indexing is the strain the operator reports. - Value is low for this workflow: agents lean on grep/read rather than LSP diagnostics/go-to-definition, and it adds noise. ## Approach 1. **Disable globally (minimal, reversible):** set `"php-lsp@claude-plugins-official": false` in `~/.claude/settings.json` `enabledPlugins`. New/resumed sessions then spawn no PHP LSP server. NOTE: an auto-mode agent may be classifier-blocked editing settings.json (cf. the 2026-07-03 permissions incident) — the operator may need to apply this directly or approve it. 2. **Decision — disable vs uninstall:** disable is reversible + sufficient; a full uninstall (`/plugin` remove, or drop from the marketplace) reclaims disk and removes it from the plugin list. Recommend disable now, uninstall later once confident it's not missed. 3. **Drain running servers:** existing LSP servers persist until their owning session ends; they clear as daemons/workers cycle (reset/respawn) or can be killed directly. No restart of flower app services needed — this is purely CC tooling. 4. **Verify:** after disabling, spawn/resume a session and confirm no new PHP LSP node process appears; the LSP process count trends toward 0 as sessions cycle. ## Constraints / non-goals - This is a Claude Code **tooling/environment** change on the operator's machine, not flower app code. Global scope affects all projects on this machine. - Fully reversible (flip back to `true`). - Do NOT touch other plugins (context-mode, frontend-design) — only php-lsp. ## Definition of done php-lsp disabled in global `~/.claude/settings.json`; new/resumed sessions spawn no PHP LSP server; LSP process count drops as sessions cycle; the disable-vs-uninstall decision is recorded.

## Objective Disable the global `php-lsp@claude-plugins-official` Claude Code plugin. It spawns ONE PHP language-server process per agent session — meaningful aggregate resource strain when many flower daemons + workers run concurrently — for a benefit the operator judges low (noise > value). ## Problem / rationale - `php-lsp@claude-plugins-official` is enabled **globally** in `~/.claude/settings.json` (`enabledPlugins["php-lsp@claude-plugins-official"] = true`); it is NOT configured at the flower project level, so it attaches to every Claude Code session on this machine. - It runs a language server **per agent** — evidence 2026-07-04: **7 LSP-ish node processes** observed concurrently (roughly one per live agent session: the standing daemons orchestrator/ops/refine + spawned workers + interactive). Idle they are light (~0.2% RAM each, ~0% CPU), but each PHP LSP can balloon to hundreds of MB while indexing the large Laravel trees here, and the flower workflow routinely runs many concurrent agents → N servers × indexing is the strain the operator reports. - Value is low for this workflow: agents lean on grep/read rather than LSP diagnostics/go-to-definition, and it adds noise. ## Approach 1. **Disable globally (minimal, reversible):** set `"php-lsp@claude-plugins-official": false` in `~/.claude/settings.json` `enabledPlugins`. New/resumed sessions then spawn no PHP LSP server. NOTE: an auto-mode agent may be classifier-blocked editing settings.json (cf. the 2026-07-03 permissions incident) — the operator may need to apply this directly or approve it. 2. **Decision — disable vs uninstall:** disable is reversible + sufficient; a full uninstall (`/plugin` remove, or drop from the marketplace) reclaims disk and removes it from the plugin list. Recommend disable now, uninstall later once confident it's not missed. 3. **Drain running servers:** existing LSP servers persist until their owning session ends; they clear as daemons/workers cycle (reset/respawn) or can be killed directly. No restart of flower app services needed — this is purely CC tooling. 4. **Verify:** after disabling, spawn/resume a session and confirm no new PHP LSP node process appears; the LSP process count trends toward 0 as sessions cycle. ## Constraints / non-goals - This is a Claude Code **tooling/environment** change on the operator's machine, not flower app code. Global scope affects all projects on this machine. - Fully reversible (flip back to `true`). - Do NOT touch other plugins (context-mode, frontend-design) — only php-lsp. ## Definition of done php-lsp disabled in global `~/.claude/settings.json`; new/resumed sessions spawn no PHP LSP server; LSP process count drops as sessions cycle; the disable-vs-uninstall decision is recorded.