[BUG] NZBGet config-write during extension install silently drops existing settings; session self-verification (queue "resumed") missed it, mislabeled as success in project notes

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

While deploying a custom NZBGet post-processing script (a "NestedArchiveUnpack" extension, added via NZBGet's own config-save mechanism) and restarting the NZBGet container to activate it, a Claude Code session's config write did not preserve NZBGet's existing settings. After the write + restart, nzbget.conf (1568 lines) contained only the 7 lines needed for the new script hookup Category6.Extensions=NestedArchiveUnpack,RemoveSamples) — every other setting was
gone:

• MainDir/DestDir/TempDir/QueueDir reverted to the unwritable default /root/downloads
• All existing categories (tv, Movies, Music, lidarr) were deleted — no CategoryN.Name/DestDir entries remained for them
• The Usenet provider (Server1.*) block was gone entirely — no news server configured at all

The session's own post-change validation checked only that NZBGet's download/post/scan queues were "resumed" (i.e., not paused) and recorded this as a successful, verified fix in the project's TODO.md. It did not diff the saved config against the pre-change config, and did not attempt a real download to confirm the pipeline still worked end-to-end. As a result, every Usenet-sourced download across three separate downstream apps (Sonarr, Radarr, Lidarr) silently failed for roughly 2 days before a user noticed (surfaced only because a specific album appeared "missing" and the user pushed back on an unrelated first explanation).

What Should Happen?

• A tool/action that saves a live application's config should read/preserve the existing config and merge in only the intended change, not risk a wholesale replace — or if the underlying API is replace-only, the agent should fetch the current full config first and re-include all existing settings in the write payload.
• Before restarting a service after a config change, the agent should back up the pre-change config (trivial, cheap) so the change is reversible.
• "Verification" after a config-mutating action should confirm the actual state that matters (e.g., all settings/categories/servers still present, and ideally a live functional check — an actual test download) rather than a shallow proxy signal (queue not paused).
• A destructive/lossy outcome from an agent's own action should never be recorded as a completed, verified success in project documentation.

Error Messages/Logs

Downstream failure symptom (Lidarr, when retrying the download):
  NzbDrone.Core.Exceptions.DownloadClientRejectedReleaseException: NZBGet rejected the NZB for an unknown reason
     at NzbDrone.Core.Download.Clients.Nzbget.Nzbget.AddFromNzbFile(RemoteAlbum remoteAlbum, String filename, Byte[] fileContent)
     at NzbDrone.Core.Download.UsenetClientBase`1.Download(RemoteAlbum remoteAlbum, IIndexer indexer)
     at NzbDrone.Core.Download.DownloadService.DownloadReport(RemoteAlbum remoteAlbum, IDownloadClient downloadClient)

  NZBGet's own container logs, repeating for every queued item since the restart:
  /root/downloads/nzbget.log: Permission denied
  [ERROR] Could not create file /root/downloads/tmp/nzb-62.tmp
  /root/downloads/nzbget.log: Permission denied
  [ERROR] Could not create file /root/downloads/tmp/nzb-63.tmp
  ... (repeats per item)

  NZBGet's live config confirmed via its own JSON-RPC API post-incident:
  MainDir = /root/downloads
  TempDir = /root/downloads/tmp
  DestDir = /root/downloads/dst
  QueueDir = /root/downloads/queue
  (no `Server1.*` entries returned at all; only category entry present was `Category6.Extensions=NestedArchiveUnpack,RemoveSamples`, with no `Category6.Name`/`DestDir`)
  
  The session's own project-file account of the change (written as a completed, verified task):
  > "installed `NestedArchiveUnpack` v1.0.0 as a versioned NZBGet v2 post-processing extension... NZBGet was restarted idle to activate the saved configuration and its download/post/scan queues were confirmed resumed afterward."

Steps to Reproduce

1. Have a running NZBGet instance with a working configuration (Usenet server credentials, categories, custom MainDir/DestDir paths already set).
2. Ask Claude Code to add a custom post-processing script/extension to NZBGet and enable it via NZBGet's config-save mechanism.
3. Have the agent save the new config and restart the NZBGet container to activate it.
4. Inspect nzbget.conf after the restart, or query NZBGet's live config via its JSON-RPC config method.
5. Observe that settings not explicitly included in the agent's config-save payload (server credentials, categories, directory paths) are gone, while the agent's own task tracking records the change as done and verified based only on

queue-resume status.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.234 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_