secure-devtools

How to check whether your developer machine is compromised

By Isaac Bell · Updated · Applies to am-i-hacked 2.0.1

Run npx am-i-hacked --system. It is a read-only audit that needs no root or sudo and makes no network calls. It checks login persistence (launchd on macOS, systemd user units and autostart on Linux) and the code signatures of what they launch, the crontab, shell startup files, AI coding tool config, and running processes. Pair it with npx am-i-being-recorded for screen-capture capability. Neither is antivirus: a clean result means no warning signs were found.

What the system scan checks

AreaWhat it looks for
Login persistencelaunchd agents and daemons on macOS; systemd user units and XDG autostart on Linux; the user crontab. The scripts those entries launch are read for clipboard, keystroke or screen capture and exfiltration endpoints.
Code signatures (macOS)A vendor-labelled login item signed by a Team ID the vendor does not use, or unsigned (HIGH); a signature that fails verification; unsigned programs in user-writable places
Shell startup filesRemote scripts piped to a shell, decoded payloads, DYLD_INSERT_LIBRARIES or LD_PRELOAD, TLS checks disabled, a forced NODE_OPTIONS --require, sudo or ssh replaced by an alias, a redirected AI API base URL, a proxy or extra certificate authority
AI coding tool configUser-level and managed settings for Claude Code, Codex, Cursor, Gemini CLI, OpenCode and Kilo Code: permission bypass, redirected API URLs, plain-text keys, MCP servers that run unpinned code, and hooks that run from writable places or observe your prompts
Running processesInterpreters running capture scripts or scripts from staging areas such as Downloads, caches and /tmp
Dark corners (next release)Folders where tooling installs code outside any project: virtualenvs, pip and uv caches, pyenv, pipx, the npx cache, the pnpm store, cargo, bun, deno, go and gem bin folders

Run it

npx am-i-hacked --system             # the folder you are in, plus this machine
npx am-i-hacked --system --verbose   # also list every login item with its signer
npx am-i-being-recorded              # browser extensions that can capture the screen

The system scan needs bash 3.2+ and jq; it does not need ripgrep. It reads shell startup files and AI-tool config, which can hold secrets; it never prints secret values.

Reading the results

  • HIGH and MEDIUM findings exit 1. INFO lines are context.
  • A finding you have reviewed and accept goes in ~/.config/am-i-hacked/host-allow.txt as <finding id> | <reason>. Allowed findings are listed on every run, never hidden.
  • For a single macOS login item you are unsure about, follow how to tell whether a login item is malware.

If something real turns up

  1. Do not run the suspect script to see what it does.
  2. Preserve evidence first: copy the plist or unit file and the program it runs, and record SHA-256 hashes and modification times.
  3. Only then stop and remove the item.
  4. If capture was involved, treat everything copied or typed since the item appeared as exposed. Rotate secrets from a different, clean device.

Limits

It looks for warning signs; it is not antivirus and does not look up known malware. System-wide Linux units and /etc/cron.* are not covered yet. A clean result does not prove the machine is safe.