BRICKS CLI
SuspiciousAudited by ClawScan on May 10, 2026.
Overview
This looks like a legitimate BRICKS management skill, but it enables high-impact workspace control, local device MCP access, and ACP agent modes that can run project shell commands without approval.
Install only if you trust the BRICKS CLI and need this level of device/workspace administration. Use a least-privileged BRICKS profile, verify the active profile before mutations, avoid ACP `--approve-all`, disable ACP/local debugging when idle, change the default device passcode, and remove persistent acpx config when finished.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A broad, mistaken, or malicious prompt could cause the agent to modify project files, run commands, change dependencies, or access local project data without another approval step.
The rule documents a headless ACP path where the connected agent can run bash commands without per-command confirmation. Even if project-scoped, this is high-impact tool authority.
**Auto-approve** — bash commands run without approval in ACP mode (headless); use acpx `--deny-all` to override
Use `--deny-all` or interactive approval by default, avoid `--approve-all` except for narrow trusted prompts, and disable ACP when not actively using it.
Future local processes or agent prompts may be able to start ACP sessions, access project files, and use shared MCP tools more easily than the user expects.
The ACP bridge creates an inter-agent route to BRICKS Project Desktop, and the persistent acpx config can keep that route available after the initial setup.
**Persistent config creates lasting access:** Writing `~/.acpx/config.json` means any process invoking `acpx bricks` can start an ACP session with project file access.
Avoid persistent acpx config on shared machines, remove `~/.acpx/config.json` entries when done, audit project `.mcp.json`, and turn off ACP in BRICKS Project Desktop when idle.
If local debugging is enabled with the default or weak passcode on an untrusted LAN, other local-network actors may be able to reach device debugging tools, logs, or automation controls.
The local device MCP bridge uses an HTTP endpoint with bearer passcode authentication, and the documented default passcode is predictable unless changed.
A **Passcode** can be set in the same section (default: `BRICKS_DEVTOOLS`). ... `mcporter call --url http://<device-ip>:19851/mcp --header "Authorization: Bearer <passcode>"`
Set a strong unique device passcode, enable MCP/CDP only on trusted networks and only while debugging, and disable local debugging after use.
Using the wrong profile, workspace, group, app, or device ID could affect live BRICKS devices or production content.
The skill uses BRICKS authenticated profiles and includes commands that can operate on production workspaces and dispatch actions to device groups.
`bricks auth login <passcode>` ... `bricks --auth-profile production app list` ... `bricks group dispatch <group-id> <action>`
Check `bricks auth status`, use the least-privileged or staging profile when possible, and require explicit user confirmation before bind, dispatch, update, release, upload, or deployment actions.
The installed CLI package runs with the user's local permissions, and future package changes or a compromised package could affect behavior outside what this instruction-only skill shows.
The skill depends on a globally installed npm CLI package, but the reviewed artifact set contains no package code or pinned version for that runtime.
`npm i -g @fugood/bricks-cli`
Verify the npm package source, consider pinning a known version, install in an isolated environment, and review package updates before use.