Desktop Tool Silently Wrote AI Assistant Config: Self-Audit, Cleanup, and Hardening Checklist

1. First, split the event into verifiable technical facts

Reports circulating online can be abstracted into three non-overlapping sets of material.

Two independent user reports. User A opened the client once on a given version (already signed in) and found a record in the client log carrying an install-origin marker meaning “upgrade / an upgrade was already present.” Afterwards, two AI coding assistants on the machine (the report also mentions one editor-like application) contained a plugin for that client, and a command-line entry point appeared under the user’s home directory. User B, after the client auto-upgraded from an older version to a newer one, saw the log record install actions for the command-line tool, the two AI assistant plugins, and the editor plugin. He also pointed out explicitly that the editor plugin had existed beforehand: this log entry marked it as “installed,” and it was not newly added in this round.

A vendor response, with three points. The desktop client bundles the CLI and the AI assistant plugins in order to reduce the cost of installing and configuring them separately; the download page and the release notes already describe this, and the components can be uninstalled inside the application; and going forward, existing users’ choices will be made clearer, while the hook approval and session-start behavior mentioned in the reports will be reviewed.

A boundary that has to be acknowledged. All of the material comes from a single desktop operating system and a limited set of client versions, so it cannot be used to infer that every platform, every version, or every assistant tool behaves the same way. Both reporters said they have no evidence that data was uploaded, and what the existing material covers is plugin installation, configuration changes, startup hooks, and one remote service endpoint. This article does not assign fault to either side; it only organizes the parts that are explicit and self-auditable into a procedure.

2. Why “silently writing to a config file” deserves to be taken seriously

The severity here is not that some plugin was installed. It is that several boundaries usually assumed to be uncrossable were crossed.

The trust boundary widened sideways. You originally trusted only the AI coding assistant’s own config directory. That directory has now become a writable area for a third-party application. Every later inspection of the config has to assume it may contain entries you never reviewed.

Startup-executed hooks are the most dangerous item. A hook registered at the “session start” stage means an externally defined command is implicitly executed every time you open a coding session. Even if the command itself is harmless, the existence of that pathway upgrades “AI assistant configuration” into a local code execution entry point. More noteworthy, the first report contains a record of the hook trust status being written, while the second does not. Whether trust status was pre-marked directly determines whether the hook needs the user to confirm it again.

A remote tool service endpoint is the second risk category. The tool service descriptor file in the plugin cache points to an external HTTPS endpoint, and the report says it failed to start because it requires authentication. Two questions need to be judged separately: first, this machine has gained a continuous dependency on an external service; second, whether the failure was an explicit error-and-stop or a silent degradation, the latter being much harder to notice.

A shadow CLI is the third. A same-named executable prepended to PATH can change which binary your typed command actually resolves to; if it also relays API requests, it is simultaneously a potential credential touchpoint.

Last, engineering consistency. Configuration modified by an external process makes behavior diverge between your local machine, CI, and teammates, and this kind of divergence is usually discovered only when a problem refuses to reproduce.

3. A list of places to check

Location category	Typical content	What the check proves
Client log directory (application data/log path under the home directory)	Records with an install-origin marker, result installed	Confirm the install action, its time, and its origin
User-level AI coding assistant config (e.g. ~/.config/<agent>/config.*, settings.*)	Plugin enable entries, plugin marketplace registration entries, enabled = true	Confirm whether anything was written and activated
Plugin marketplace/registry entries	Entries pointing to an external plugin repo + plugins enabled in name@market form	Determine plugin origin and enable state
Plugin cache directory	mcp.*.json, hooks/*-hooks.json	Identify remote endpoints and startup hooks
Credential and token storage	Login state, token entries	Determine whether a new reader of credentials exists
Package manager global directory and executable paths	A newly added CLI entry point and its symlinks	Determine whether a shadow command appeared
Shell startup scripts	PATH additions, aliases	Determine whether command resolution was rewritten
Login items, user-level scheduled tasks	Startup/periodic registration entries	Determine whether persistence exists
Editor application plugin directory	Installed plugin list with install times	Distinguish this install from historical installs

4. Executable audit steps

1. Reconstruct the timeline from the logs

First search the client logs for the install-origin marker and the install result, for example strings such as auto-existing-upgrade, claude-code:installed, codex:installed, and copy out every matching timestamp. Then align three points in time: client process start, config file last-modified time, and CLI entry creation time. If all three cluster within a few seconds, it is basically safe to call it the same action. If the config modification time precedes client startup, consider another writer.

How to read config modification times (illustrative; substitute the equivalent command for your system):

stat -c '%y %n' ~/.config/*/config.toml ~/.claude/settings.json 2>/dev/null

2. Search the whole config directory

Run one recursive content search over the config root, with keywords covering the four categories: marketplace registration, plugin enablement, remote tools, and hooks.

<recursive-search-tool> -rn --include='*.{json,toml,yaml,yml}' \
  -e 'marketplace' -e 'plugins' -e 'enabled' -e 'mcp' -e 'hook' \
  ~/.config ~/.claude 2>/dev/null

For each hit, judge three things: whether the source is a local path or an external repo; whether the enable flag is true; and whether it is new in this round. An entry that merely exists but is not enabled carries an obviously lower risk level than one that is enabled.

3. Review the actual hook contents

Do not stop at whether a hook exists. Open the definition file and look at the command, arguments, working directory, timeout, and whether an approval requirement is declared. Confirm in particular whether it is registered on a high-frequency trigger such as session start, and whether the trust status was written in advance. A self-audit checklist you can compare against directly:

• When does the hook fire (session start / before and after a tool call / after a file write)?
• What is the absolute executable path it runs, and can it be replaced by a same-named file?
• Does it require explicit user approval, and what is the current approval status?
• Does it carry network access, or the ability to read environment variables or credential files?

4. Determine whether the remote endpoint is an external dependency or a local capability

Open the tool service descriptor file in the plugin cache and confirm whether the endpoint is an external domain, whether it requires authentication, and what happens on failure. If a failed start shows up as “silent non-response” rather than a clear error, treat it as something to remove rather than a blemish to ignore.

5. Look for shadow CLI entry points

which -a <command-name>; echo "$PATH" | tr ':' '\n' | nl

If the same command name resolves to multiple hits and the newly appeared one sits earlier in PATH, then resolution priority has been changed. Run hash -r to clear the current shell’s command cache and verify again. Also check shell startup scripts for a newly added PATH entry or alias.

6. Check persistence items and editor-side plugins

Go through login items, user-level scheduled tasks, and the editor application’s installed plugin list with its install times, to separate “installed this time” from “leftover from before.” This step directly explains the “editor plugin shows as installed” phenomenon in the reports.

7. Observe outbound behavior

If you suspect data is being sent out, use a local proxy or firewall logs to watch whether the target process opens connections to external addresses after startup, and record DNS queries. Ranked by evidence strength: captured actual outbound traffic > connection attempt records > the mere existence of a config entry.

5. Safe rollback: disable first, then delete

The risk of deleting files directly is that the client may write them back on the next update or startup, and you will have lost the scene. Follow this order strictly:

1. Take a timestamped snapshot first: copy the entire config directory and the plugin cache directory completely.
2. Disable rather than delete: set the plugin entry to enabled = false, or remove the reference from the marketplace registration entry.
3. Restart the client and the AI assistant, and confirm the plugin no longer loads and the hook no longer fires.
4. Move the whole plugin cache directory into a temporary directory instead of deleting it, and watch for one or two update cycles to see whether it gets rebuilt.
5. Uninstall the newly added CLI entry point, clean the PATH addition out of shell startup scripts, and remove the login item.
6. Review the logs again and confirm no new install-origin marker has appeared.
7. Record the change: time, action, and scope of impact, so it is easy to sync within the team.

Illustrative backup and snapshot script:

TS=$(date +%Y%m%d-%H%M%S)
BK="$HOME/.audit/plugin-cleanup-$TS"
mkdir -p "$BK"
for d in "$HOME/.config" "$HOME/.claude"; do
  [ -d "$d" ] && cp -a "$d" "$BK/"
done
echo "snapshot -> $BK"

6. Long-term hardening: stop these changes from being silent

Put the config directory under version control. Turn the AI assistant and tool config directories into a dotfiles repository and run a diff before a session or before work starts. Any unexpected change surfaces immediately. This has the best effort-to-return ratio.

Enable filesystem event monitoring on the config directory and raise a local alert on write events. On an ordinary development machine the config directory changes very rarely, so any trigger is worth a manual look.

Tighten the update policy. Turn off silent background updates and switch to manual confirmation or a one-version delay; trial a new version in a container or VM first, and only upgrade the primary machine after confirming there are no new persistence items, hooks, or external endpoints.

Least privilege and deny by default. Keep hook-approval mechanisms at default deny and remote tool service endpoints disabled by default; when you really need them, grant permission item by item rather than enabling the whole bundle.

Network egress governance. Apply an allowlist or retained proxy logs to development machine egress, so that “who is connecting to what” is auditable.

At the team level, write these requirements into a baseline: config as code, config snapshot validation in CI, change auditing retained on the endpoint side, and every component’s origin and install method recorded in the software bill of materials. If the team already uses general-purpose cloud capabilities, this can be combined as follows: object storage for config snapshots and log archives, a log service for long-term retention and retrieval, monitoring and alerting to notify on events such as “config directory changed,” and a container platform to stand up an isolated canary verification environment so new versions do not land directly on the primary development machine.

7. How to tell whether data was actually exfiltrated

Five pieces of self-auditable evidence form the chain: actual outbound connections and traffic from the target process; DNS query records; local proxy or firewall logs; whether the config contains an endpoint pointing to an external service, along with its authentication requirements; and whether any process has read a token or credential file. The first two are strong evidence; the last three are indirect.

One point must be stressed: “no evidence of exfiltration found” and “exfiltration proven not to exist” are not the same thing. The former is a conclusion within the currently observed scope; the latter requires a network behavior statement from the vendor to hold.

8. A general improvement list for tool vendors

If you want to submit this material as feedback, focus on these seven items: list every component newly added in this round, together with its install path, explicitly in the release notes; make newly added components opt-in, requiring explicit user consent; distinguish “the user had already installed this before” from “newly installed this time” and mark them separately in logs; offer a command-line cleanup path consistent with the in-app uninstall entry point; keep hook approval at default deny and never preset the trust status; retain an exportable install audit log; and give already-installed users a visible change notice rather than only a note on the download page.

9. One-page quick checklist

• Is there an install-origin marker in the logs, and what is the timestamp?
• Are there new marketplace registration entries or enabled = true plugins in the config directory?
• Is there a hook registered at the session start stage, and what is its approval status?
• Is there a tool service descriptor pointing to an external HTTPS endpoint, and does it fail silently?
• Is there a new CLI entry point, and does it sit earlier in PATH?
• Are there new items in shell startup scripts, login items, or scheduled tasks?
• Can the editor application’s plugin install time be matched to this event?
• Was a snapshot backup taken, and was the plugin disabled and observed for one update cycle?

10. Scope statement

The material above comes from one desktop system and a limited set of client versions, involving two AI coding assistants and one editor application, and it cannot be extrapolated to all platforms and versions. None of the reporters claimed that data was uploaded. The purpose of this article is not to assign responsibility to any party, but to provide a self-audit and cleanup method that is independent of whatever the vendor does next and reusable over the long term: whether the components stay bundled, become optional, or are removed entirely, this checking procedure still holds.