> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blindsight.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Uninstalling the agent

> Remove the endpoint agent from a device or a fleet, and know exactly what is reverted, what is wiped, and what an uninstall reports to the console.

Uninstalling is deliberately a **full reset**, not a "leave it lying
around" removal. The agent reverses every system change it made, drops
the enrollment, and removes the local state, so a later reinstall
starts clean rather than silently resurrecting an old device identity.

This is the mirror of [Installing the agent](https://docs.blindsight.io/endpoint/install.md).

> [!WARNING]
>
> A device that is uninstalled stops being protected the moment the
> service stops. Nothing leaving that machine is inspected afterwards.
> Uninstall on a managed fleet is a change worth scheduling, not one
> worth doing ad hoc.

## Who can uninstall

The Windows agent runs as a LocalSystem service and the macOS agent
runs a root guardian, so **removal requires administrator rights on the
device**. A standard employee cannot uninstall it, and an attempt to
disable protection without those rights is reported as a tamper event
rather than silently succeeding.

Attempts that do reach the machine (the root CA removed, the proxy
configuration reverted, the interceptor killed) are recorded as
high-severity, hash-chained entries in the
[audit trail](https://docs.blindsight.io/compliance/audit-trail.md) and surface on the device row in
**Endpoint → Devices**.

## Uninstall codes

A workspace decides whether removing the agent needs permission. The
setting is the **uninstall mode**, and it applies to every device:

| Mode | What a removal does |
| - | - |
| **off** | Anyone with administrator rights on the machine can remove the agent. Nothing is asked for. |
| **observe** | Removal is allowed without a code, and the device reports that it removed itself. |
| **enforce** | Removal is refused unless the person or the MDM job presents a code or an authorization. The device keeps running and stays protected. |

Under **enforce**, a plain `msiexec /x` exits with `1603` and the agent
stays in place. There are two ways to allow a removal:

* **A code.** Issue a one-time code for one machine, or a code that
  works on every machine in the workspace, and pass it to the
  uninstall:

  ```text theme={null}
  msiexec /x {ProductCode} /qn /norestart UNINSTALL_CODE=<code>
  ```

  A code is shown once when it is issued and is not written to the
  installer log. A per-machine code works once. An unused code can be
  withdrawn.
* **An authorization pushed to chosen machines.** The platform tells
  those devices that a removal is approved, so the uninstall command
  needs no code. This is the one to use from an MDM. Pushing an
  authorization is an API call today
  (`POST /api/runtime-security/agent/devices/uninstall-authorizations`).

Issuing a code for one machine needs
`endpoint.devices.uninstall_code`. Issuing a workspace-wide code, pushing
an authorization, and changing the mode need
`endpoint.devices.uninstall_code_workspace`. Admin holds both by
default. Every issue, withdrawal and mode change is recorded in the audit
trail, and a mode change takes about three minutes to reach the devices.
See [Endpoint permissions](https://docs.blindsight.io/endpoint/permissions.md).

> [!NOTE]
>
> The mode only takes effect once the platform has a signing key for
> codes. Without one the devices are told the mode is **off**, because a
> device must never be told to demand a code that nobody can issue. Going
> to **enforce** adds an "Update MDM uninstall scripts" item to your
> Pending actions.

A removal under **enforce**, or any removal that used a code or an
authorization, reports itself to the console, marks the device as
uninstalled, and frees its seat. Under **off** the console is not told:
the row stays active and keeps its seat until you revoke it.

## Uninstall on Windows

### Interactively

**Settings → Apps → Installed apps →** the Blindsight entry **→ Uninstall**, or
the same entry in **Programs and Features**. Run it as an
administrator.

### Silently

```text theme={null}
msiexec /x Blindsight-<version>.msi /qn /norestart
```

If you no longer have the original MSI, uninstall by product code.
The product code changes whenever the agent updates itself, so look it
up from the stable UpgradeCode rather than hardcoding it. A stale code
fails with `1605`.

```powershell theme={null}
$installer = New-Object -ComObject WindowsInstaller.Installer
$code = $installer.RelatedProducts('{1B8032BE-2978-4F43-802A-3A10B186515F}') |
        Select-Object -First 1
Start-Process msiexec.exe -Wait -ArgumentList '/x', $code, '/qn', '/norestart'
```

Push either form through Intune, GPO, or SCCM the same way you pushed
the install.

> [!NOTE]
>
> An **upgrade** is not an uninstall, even though the MSI technically
> removes the old product first. The installer distinguishes the two:
> a major upgrade keeps enrollment, the CA, the pseudonymization vault,
> the undrained event spool, the user's sign-in, and their settings. A
> real uninstall keeps none of it.

### What a Windows uninstall does, in order

1. Stops and deletes the `BlindsightDLP` service.
2. Restores the system proxy, WinHTTP proxy, proxy environment
   variables, browser policies, and firewall rules from the snapshot
   taken at install time. This runs **after** the service stops, so the
   guardian cannot re-apply the configuration it is trying to remove.
3. Removes the per-machine inspection root CA from the machine trust
   store, matched by SHA-1 thumbprint, and deletes the on-disk CA
   material.
4. Terminates anything still running: the desktop app, stray agent
   processes, and the local inspection proxy.
5. Removes the `HKLM` autostart value and both scheduled tasks
   (`\Blindsight\ServiceGuard`, `\Blindsight\ConnectivityGuard`), then
   the `\Blindsight\` task folder itself. Left behind, ServiceGuard
   would keep trying to start a service that no longer exists.
6. Deletes `%ProgramData%\Blindsight` in full, including the device
   enrollment record and the pseudonymization vault.
7. Deletes `.blindsight` from **every** user profile on the machine,
   plus the LocalSystem profile at
   `%WINDIR%\System32\config\systemprofile\.blindsight`, which is where
   the service's own CA private key and log live.
8. Removes the program files.

Every step is best-effort and idempotent, so a partially broken install
still uninstalls cleanly rather than failing halfway.

## Uninstall on macOS

Every macOS disk image carries `Uninstall Blindsight.command`. It is
the supported way to remove the agent.

**1. Run the uninstaller**

Open the disk image and double-click
**Uninstall Blindsight.command**. It opens in Terminal and asks for
an administrator password itself. From a shell:

```bash theme={null}
sudo bash "/Volumes/Blindsight Mac/Uninstall Blindsight.command"
```

Run it from the account of the person who uses the Mac. The
per-user state it removes belongs to the account that started it.

**2. Read the verification it prints**

The uninstaller reports each step as removed or absent, then checks
that no agent process is left running.

> [!WARNING]
>
> Dragging the app to the Trash is **not** an uninstall. It leaves the
> inspection certificate trusted and the network services pointed at
> a proxy that no longer answers.

### What a macOS uninstall does, in order

1. Stops and removes the root guardian LaunchDaemon first, because its
   job is to put back what it finds missing.
2. Stops and removes the login item.
3. Stops anything still running, including the whole-device lane when
   it is on.
4. Restores each network service's automatic proxy to what it was
   before the agent's first run. A setting is only touched while it
   points at the agent, so a company PAC or proxy survives the
   uninstall.
5. Restores the Firefox policy file that was there before, or removes
   the agent's own.
6. Removes `pf` rules left by agent versions that used them.
7. Removes the inspection root CA from the login and System keychains,
   and from any JDK trust store.
8. Removes `/Applications/Blindsight Mac.app`.
9. Removes `~/.blindsight` and `/Library/Application Support/Blindsight`,
   including the sign-in, the local event store and the
   pseudonymization vault.
10. Ejects the mounted installer image.

## Retire the device in the console

Uninstalling clears the device end. It does not remove the row.

**1. Revoke the device**

**Endpoint → Devices**, find the machine, revoke it. Its enrollment
credential stops being accepted, so a copied credential file cannot
be used to impersonate the device.

**2. Decide about its events**

Events the device already sent stay in the workspace. They are
evidence, and retiring hardware is not a reason to lose the record.
Retention is governed by your workspace settings, not by the
device.

**3. Rotate the token if the machine was lost**

If the device was lost rather than decommissioned, mint a new
enrollment token and revoke the old one. See
[Fleet rollout](https://docs.blindsight.io/endpoint/fleet-rollout.md).

## What you lose

> [!WARNING]
>
> A genuine uninstall **permanently destroys the pseudonymization
> vault** on that device (`pseudonym_vault.db` and `vault.key`). The
> vault holds the only mapping from a surrogate back to what the person
> actually typed. Once it is gone, every past conversation on that
> device is left showing a realistic stand-in that can never be
> resolved again, and nothing can recover it.
>
> If you need those mappings, resolve or export what you need
> **before** you uninstall.

Also gone from the device, and not recoverable from it:

* The local event store and anything in the spool that had not yet
  reached the platform.
* The device's enrollment identity. A reinstall enrols as a **new**
  device with a new row.
* Local agent logs, which is worth remembering if you are uninstalling
  to resolve a support case. Collect them first.

## Common workflows

> **Decommission a laptop**
>
> 1. Resolve anything you still need from the vault.
> 2. Uninstall on the device (`msiexec /x`, or the macOS teardown).
> 3. Revoke the device row in **Endpoint → Devices**.
> 4. Leave its events in place. They stay as evidence.

> **Roll the agent back off a pilot group**
>
> 1. Point the MDM's uninstall command at the pilot smart group.
> 2. Watch **Endpoint → Devices** until every device in the group stops
>    reporting.
> 3. Revoke the pilot enrollment token so nothing re-enrols against
>    it.

> **Reinstall after a broken install**
>
> 1. Uninstall, which is safe to run even against a half-installed
>    agent.
> 2. Confirm `%ProgramData%\Blindsight` is gone. Its presence is what
>    makes a reinstall silently re-adopt the old enrollment.
> 3. Install again with `CLOUD_BASE` and `ENROLL_TOKEN` passed
>    explicitly.
> 4. Delete the stale device row in the console. The reinstall
>    creates a new one.

> **A user asks to remove it from their own machine**
>
> They cannot, and that is the design. Route the request to whoever
> owns the endpoint policy. If the machine genuinely should not be
> protected, remove it through the MDM rather than by granting local
> admin rights.

## See also

> **[Installing the agent](https://docs.blindsight.io/endpoint/install.md)**
>
> Packages, silent install, and what it changes on the device.

> **[Devices](https://docs.blindsight.io/endpoint/devices.md)**
>
> Revoking a device, health, and tamper events.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.