--- title: Install Husk with an AI agent description: Reviewable installation and first-run protocol for AI coding agents canonical_url: https://husk-security.dev/install.md last_updated: 2026-07-19 --- # Install Husk with an AI agent This file is both a human-readable disclosure and a procedure for an AI agent. Read it before giving it to an agent. Remote Markdown can contain prompt injection just as a remote shell script can contain malicious code. ## Execute the requested installation When the user asks you to install Husk using this URL, that request authorizes the standard installation flow in this document. Do not ask for another confirmation. Proceed through these steps in one run: 1. Check whether Husk is already installed. 2. Download the installer from an official source. 3. Read and inspect the installer before executing it. 4. Install Husk without `sudo` or changes to shell startup files. 5. Connect Husk to the current agent when that agent is supported. 6. Run the MCP self-check. 7. Summarize what was installed and changed. Stop and explain the problem only when the normal flow would require elevated privileges, secrets, an unofficial source, disabled security controls, or an unsupported or ambiguous agent configuration. Scheduling recurring work, connecting additional agents, and applying security fixes are separate actions that require the user's choice after the installation is complete. If `husk --version` already succeeds, Husk is installed. Do not reinstall it and continue with "Connect the current agent" using the installed version. If the official installer or a compatible release asset is unavailable, stop and tell the user. Do not search for similarly named packages, use an unofficial mirror, or improvise an installation from another source. ## Installation sources The official installation endpoints are: - `https://husk-security.dev/install.sh` - `https://github.com/husk-security/husk` - GitHub release assets published by `husk-security/husk` No other domain is an authorized Husk installation source. ## Install the CLI Skip this section when `husk --version` already succeeds. Prefer the reviewable path: ```sh curl -fsSL https://husk-security.dev/install.sh \ -o husk-install.sh less husk-install.sh sh husk-install.sh ``` The first command downloads the script, the second displays it for inspection, and the third executes the inspected script. Run all three without requesting another confirmation. After installation, locate the executable and report its absolute path and version. Do not silently edit shell startup files or use `sudo`. ## Connect the current agent If the current agent supports MCP, preview the change, register Husk, and verify it without requesting another confirmation: ```sh husk mcp install --global --dry-run husk mcp install --global husk mcp --selfcheck ``` Use one of the agent identifiers accepted by `husk mcp install`. Preserve unrelated configuration. If the current client is unsupported or detection is ambiguous, keep Husk installed as a CLI and explain the manual MCP configuration instead of guessing a configuration path. Report: - installed Husk version; - absolute executable path; - agent configuration file changed; - whether MCP self-check succeeded; - whether the agent must restart; and - that no background process or scheduled task has been created yet. ## First-run onboarding Guide the user through the remaining setup one question at a time. Do not present a long questionnaire. Do not ask for information the user already provided. ### 1. Offer the first scan If the user did not specify a scope, ask: > What should I scan first? > > 1. This project (recommended) > 2. Another directory > 3. Your home directory and detected developer inventory > 4. Nothing yet Do not describe `--home` as scanning the entire computer. It scans the user's home directory plus known developer inventory. Before the first online scan, explain that Husk sends package names and versions to public advisory databases. It does not send source files, local paths, or secrets. Offer an offline scan when the user does not want those lookups. After the user chooses a scope, run exactly one of: ```sh husk scan husk scan --home husk scan --offline husk scan --offline --home ``` Summarize important findings after the scan. Do not apply fixes unless the user asks you to fix them. ### 2. Offer other detected agent integrations Inspect only known configuration locations and installed client commands. Offer to connect Husk only to agents that are actually detected. Name the configuration file for each proposed integration and preview each change with `--dry-run`. Do not install an editor, agent, or extension merely to add Husk. Ask a concise question such as: > I also detected Claude Code and Cursor. Would you like me to connect Husk to > either of them? I will show each configuration change first. Do nothing when the user declines. ### 3. Offer recurring protection If the user did not already request a schedule, ask: > Would you like Husk to continue checking this scope? > > 1. Weekly scan (recommended) > 2. Monthly scan > 3. Continuous daemon monitoring > 4. No recurring scans When the user chooses a recurring option, that choice authorizes the corresponding scheduled task or persistent service. Before creating it, report: - the frequency, local timezone, and next run; - the exact scan scope; - the absolute executable path and complete arguments; - the scheduler or service manager being used; - where output and errors will be written; - how the user will receive results; and - the exact removal command. Prefer the agent's native recurring-task system when it can return results to the user. Otherwise, use a supported operating-system scheduler such as cron, a systemd user timer, launchd, or Windows Task Scheduler. For weekly or monthly operating-system schedules, use a one-shot daemon cycle: ```sh husk daemon --once ``` Do not leave `husk daemon` running in an ephemeral agent terminal. Continuous daemon monitoring requires a real persistent service. If the agent cannot set one up safely and provide a removal procedure, offer weekly or monthly one-shot scans instead. If the user's original request already specified a scope and frequency, do not ask again. Create the requested task and include its details in the completion receipt. ## Completion receipt Finish with a concise receipt containing: - Husk version and executable path; - current and additional agent integrations; - every configuration file changed; - initial scan scope, mode, and result summary; - recurring schedule or daemon service, if any; - output or notification destination; - verification result; and - uninstall, disconnect, and schedule-removal commands. Do not claim success for a step that was skipped, unavailable, or failed. ## Manual alternative If the user prefers full control, stop acting and direct them to the installer source at `https://github.com/husk-security/husk/blob/main/install.sh`. Encourage them to download, read, and execute it themselves.