BRICKS CLI

CLI for BRICKS Workspace API — manage devices, apps, modules, and media.

Scope note: This skill covers cloud API operations (device/app/module/media management) and local-network device interaction (LAN discovery, MCP bridging). The use-desktop-acp rule extends scope further to include bridging with the BRICKS Project Desktop agent, which shares sessions and can execute commands in project context. See the Security section below for details.

Installation (if not yet)

CODEBLOCK0

Authentication

CODEBLOCK1

Global --auth-profile Flag

Use -ap or --auth-profile to override the active profile for any command, without switching the stored profile:

CODEBLOCK2

Priority: --auth-profile flag > BRICKS_PROFILE env > stored current profile.

Device Management

List & Info

CODEBLOCK3

Control

CODEBLOCK4

Screenshot

CODEBLOCK5

Monitor (Interactive-tty needed)

CODEBLOCK6

Device Groups

CODEBLOCK7

Applications

CODEBLOCK8

Modules

CODEBLOCK9

Project Init Options

Both app and module support these flags:

• - -o, --output <dir> — output directory
• INLINECODE9 — skip prompts, use defaults
• INLINECODE10 — skip git initialization
• INLINECODE11 — skip INLINECODE12
• INLINECODE13 — skip GitHub Actions workflow
• INLINECODE14 — skip AGENTS.md
• INLINECODE15 — skip CLAUDE.md
• INLINECODE16 — include GEMINI.md (off by default)

Media Flow

CODEBLOCK10

Config

CODEBLOCK11

Interactive Mode (Interactive-tty needed)

CODEBLOCK12

DevTools (LAN Discovery)

CODEBLOCK13

Devices must have "Enable LAN Discovery" turned on in Advanced Settings (on by default).

MCP Server

CODEBLOCK14

Bridging Device MCP to Local CLI

Use mcporter to bridge a device's MCP endpoint as a local MCP server (STDIO), so tools like Claude Code can connect to it:

CODEBLOCK15

ACP Bridge (BRICKS Project Desktop)

Connect external ACP clients to the running BRICKS Project Desktop (docs).

CODEBLOCK16

The bridge pipes ACP JSON-RPC over stdio ↔ the app's Unix socket (~/.bricks-project-desktop/acp.sock). It shares the app's sessions and MCP state.

Security: Commands executed through the ACP bridge run in the project's working directory. Only enable ACP when actively needed, and prefer --deny-all over --approve-all when automating. See the Security section and rule use-desktop-acp for details.

See rule use-desktop-acp for full usage with acpx and OpenClaw.

Rules

• - connect-local-device — Deploy the current app to a local LAN device, then monitor status, debug, and run automations via MCP
• INLINECODE23 — Connect to the BRICKS Project Desktop agent via ACP for headless prompting, session management, and multi-agent orchestration

Security

• - Auto-approve risk: Running acpx --approve-all allows the bridged agent to execute bash commands without confirmation. Prefer explicit approval or --deny-all for untrusted prompts. Never combine --approve-all with persistent config in unattended/shared environments.
• Persistent config: Creating ~/.acpx/config.json enables future ACP sessions without re-specifying the agent. This is convenient but means any process that invokes acpx bricks can start a session with project file access. Remove the config when not actively needed.
• Device passcodes: LAN device MCP bridging (mcporter) requires passing device passcodes as Bearer tokens. Treat passcodes as secrets — do not log or commit them.
• LAN discovery: bricks devtools scan broadcasts on the local network. Only run on trusted networks.

Tips

• - Use -j or --json on most commands for JSON output
• Device IDs are UUIDs — use device list to find them
• Get workspace token from: https://control.bricks.tools → Workspace Settings → API Token