CrowdStrike Falcon Command Builder

CrowdStrike Falcon Sensor Command Builder

This composer generates the exact CrowdStrike Falcon sensor command for the platform and task in front of you — install, uninstall, verify, restart, check cloud connectivity, configure a proxy, set grouping tags, or read the installed version — across Windows, macOS, and Linux. Fill in your CID, maintenance token, or proxy details and they are substituted into the command with the right syntax and the right verification step attached. Everything runs client-side: your CID and tokens stay in your browser and are never transmitted or logged.

It exists because Falcon’s sensor management syntax is genuinely inconsistent across platforms. Windows uses an installer executable and the registry, macOS and Linux use falconctl binaries at different paths with different flag conventions, and the same conceptual task — “set the grouping tags” — looks nothing alike on all three. If you administer a mixed estate, you are either keeping three sets of notes or looking it up every time.

Before You Run Anything

These are administrative endpoint-management commands, and two things follow from that.

Almost everything here needs elevation. Install, uninstall, verify, restart, proxy configuration, tag setting, and version queries all require an elevated Command Prompt or PowerShell on Windows, and sudo on macOS and Linux. The composer marks which action requires administrator privileges and prefixes sudo where appropriate. The connectivity ping is the one action that does not need elevation.

Uninstalling or stopping a sensor removes endpoint protection. A machine with no Falcon sensor is not being monitored and not being defended, and it will drop out of your console’s coverage reporting. That is why CrowdStrike gates removal behind sensor uninstall protection: with it enabled, the uninstall will not proceed without a per-host maintenance token retrieved from the Falcon console by someone with the rights to reveal it. That gate is a feature, not an obstacle — it is precisely what stops an attacker or a curious user from removing the agent. Removal should be a deliberate, change-controlled action performed during decommissioning, a supported migration, or vendor-directed troubleshooting, and never a first response to an unexplained performance problem.

What the Composer Generates

Eight actions, each rendered for the operating system you select:

• Install sensor — on Windows, WindowsSensor.exe /install with your CID=, optional /quiet /norestart, and an optional ProvToken=, followed by sc query csagent to confirm the service exists. On macOS, installer -pkg, then falconctl license <CID>, then falconctl stats. On Linux, the .deb or .rpm install, then falconctl -s --cid= with an optional --provisioning-token=, then systemctl start falcon-sensor, then falconctl -g --aid to confirm an agent ID was issued.
• Uninstall sensor — CsUninstallTool.exe MAINTENANCE_TOKEN=… on Windows with the sensor-installer alternative shown too, and falconctl uninstall --token … on macOS and Linux, each with the command that confirms removal.
• Verify running — sc query csagent (expect STATE: RUNNING), falconctl stats (expect Sensor operational: true), or systemctl status falcon-sensor plus falconctl -g --aid.
• Restart service — net stop csagent / net start csagent, launchctl unload / load of the Falcon LaunchDaemon plist, or systemctl restart falcon-sensor.
• Check console connectivity — a ping to the correct cloud host for your region (US-1, US-2, EU-1, or US-GOV-1), with a journalctl log filter on Linux.
• Configure proxy — falconctl -s --apd=FALSE --aph=<host> --app=<port> on Linux with the stop/start and read-back steps; on Windows and macOS the proxy is an install-time parameter, so the composer shows the install command with APP_PROXYNAME/APP_PROXYPORT or --aph/--app.
• Set grouping tags — falconctl -s -f --tags="…" plus a restart on Linux, a registry write plus service restart on Windows, and falconctl grouping-tags set on macOS.
• Get sensor version — a registry query or WMI lookup on Windows, falconctl stats agent_info on macOS, falconctl -g --version on Linux.

The Three Identifiers, and Which Is Which

Confusing these is the most common reason a deployment stalls, so it is worth being precise.

The CID (Customer ID) is your tenant identifier, and it is the same value for every host in your organisation. It is required at install time so the sensor knows which Falcon tenant to register with. Find it under Host setup and management → Sensor downloads in the console. It is not secret in the way a password is, but there is no reason to publish it.

The installation token (also called a provisioning token) is an optional tenant-level control that prevents anyone from installing a sensor against your CID without it. If your organisation has enabled it, an install without ProvToken= or --provisioning-token= will fail even with a correct CID — a failure mode that looks baffling until you know the setting exists.

The maintenance token is per-host and controls removal. When sensor uninstall protection is enabled, it is required to uninstall the sensor and, in current versions, to change certain protected settings. It is revealed per host in the console, and treating it as a secret is the whole point: a maintenance token in a script committed to a repository defeats the protection it exists to provide. Pass it at runtime, never hard-code it.

Troubleshooting Patterns

Sensor installed but not appearing in the console. Verify the service is running first — a sensor that is not running cannot report. If it is running, the problem is almost always network: run the connectivity check for your correct cloud region, since a host pointed at the wrong region, or blocked from *.cloudsink.net by egress filtering or TLS inspection, installs perfectly and then never checks in. On Linux, falconctl -g --aid returning no agent ID confirms registration never completed.

Uninstall fails or exits silently. Nearly always the maintenance token: absent, wrong, or from a different host. Retrieve the token for that specific machine. Note also that on Windows the preferred path is CsUninstallTool downloaded from the console rather than Add/Remove Programs, and that removal via the sensor installer needs the same token.

Proxy in place but the sensor still cannot reach the cloud. On Linux, remember that --apd=FALSE is the flag that enables proxy use — it disables the “proxy disabled” setting, which is a double negative that catches people out. Stop the sensor before changing the values, start it afterwards, and read the settings back with falconctl -g --apd --aph --app. On Windows and macOS the proxy is baked in at install time, so changing it means reinstalling or using the console-side configuration.

Tags not showing in the console. Setting tags overwrites the existing set rather than appending to it, and the sensor must be restarted before the new values sync. If a host loses its policy assignment after a tag change, that is usually why.

Frequently Asked Questions

Where do I find my CID?

In the Falcon console under Host setup and management → Sensor downloads. It is a single tenant-wide value used by every sensor you install.

What is a maintenance token and why do I need one to uninstall?

A per-host token that enforces sensor uninstall protection. With that protection enabled, the sensor cannot be removed without it — which is exactly what prevents an attacker or an end user from disabling endpoint protection. Retrieve it per host from the console.

What is the difference between an installation token and a maintenance token?

The installation (provisioning) token is tenant-level and controls who may install a sensor against your CID. The maintenance token is per-host and controls who may remove or alter one. They are not interchangeable.

Do these commands need administrator rights?

Yes, with one exception. Install, uninstall, verify, restart, proxy, tags, and version all require an elevated shell on Windows or sudo on macOS and Linux. Only the connectivity ping runs unprivileged.

How do I check whether the sensor is running?

sc query csagent on Windows and look for STATE: RUNNING; falconctl stats on macOS and look for Sensor operational: true; systemctl status falcon-sensor on Linux and look for Active (running).

The sensor installed but never appeared in the console. What now?

Confirm the service is running, then test connectivity to your cloud region’s host. Wrong region, blocked egress to *.cloudsink.net, or TLS inspection breaking the connection are the usual causes. On Linux, an empty response from falconctl -g --aid confirms registration did not complete.

Are my CID and tokens sent anywhere?

No. The composer substitutes them into the command text in your browser. Nothing is uploaded, stored, or logged. That said, treat any generated command containing a maintenance token as a secret — do not paste it into a ticket or commit it to a repository.

Is it safe to uninstall the sensor to troubleshoot a performance issue?

Not as a first step. Removing the sensor leaves the endpoint unprotected and unmonitored for as long as it is absent. Restart the service, check the version, and raise a support case first; uninstall only under change control or when CrowdStrike support directs it. For the wider picture, our security tools collection covers related endpoint and network checks, and the security model decision matrix is useful when documenting the control model your endpoint policy enforces.