AI-Native SecOps Platform

Flocks is an AI-driven SecOps platform built with Python, featuring multi-agent collaboration, HTTP API server, and modern terminal user interface designed to help you with your SecOps tasks.

• 🤖 AI Agent System - Multi-agent collaboration (build, plan, general)
• 🔧 Rich Tool Set - bash, file operations, code search, LSP integration, etc.
• 🌐 HTTP API Server - High-performance API service based on FastAPI
• 💬 Session Management - Session and context management
• 🎯 Multiple Model Support - Support for Anthropic, OpenAI, Google and other AI models
• 📝 LSP Integration - Language Server Protocol support
• 🔌 MCP Support - Model Context Protocol
• 🖼️ WebUI - Browser-based web user interface
• 🎨 TUI Interface - Modern terminal user interface

Flocks supports two deployment methods — choose one:

• uv
• Node.js with npm 22.+
• agent-browser
• bun for TUI installation (Optional)

By default, the project install scripts will try to ensure the requirements above are available automatically when possible.

If automatic npm installation fails during setup, please install npm manually and use version 22.+ or newer.

The following installation options are supported. Choose one to complete the installation, then proceed to 3.1.3 Start service.

Option A: Install with one command (recommended)

macOS / Linux

curl -fsSL https://raw.githubusercontent.com/AgentFlocks/flocks/main/install.sh | bash

Creates ./flocks under the current directory

Windows PowerShell (Administrator)

powershell -c "irm https://raw.githubusercontent.com/AgentFlocks/flocks/main/install.ps1 | iex"

Option B: Install from source code

If you prefer to inspect the repository before installation, clone it locally and run the installer from the workspace:

git clone https://github.com/AgentFlocks/Flocks.git flocks
cd flocks

macOS / Linux

sh ./scripts/install.sh

Windows PowerShell (Administrator)

powershell -ep Bypass -File .\scripts\install.ps1

Option C: Windows installer (EXE, BETA)

Flocks provides an Inno Setup wizard (.exe) for Windows x64. Download the installer for your version from the GitHub Releases page.

After installation, use the Start menu or optional desktop shortcut, or open a new terminal and run flocks start so updated PATH and related environment variables take effect. For more details, see packaging/README.md.

Use the flocks CLI to manage the backend and WebUI together in daemon mode. The start command builds the WebUI before launch by default; use flocks restart when you want an explicit full restart.

flocks start
flocks status
flocks logs
flocks restart
flocks stop

The default service address is:

• Flocks WebUI: http://127.0.0.1:5173
• Remote access configurable via flocks start --host <ip>

Flocks CLI usage: flocks --help

docker pull ghcr.io/agentflocks/flocks:latest

Run the container and mount the host user's ~/.flocks directory into the container:

macOS / Linux

docker run -d \
  --name flocks \
  -p 5173:5173 \
  --shm-size 4gb \
  -v "${HOME}/.flocks:/home/flocks/.flocks" \
  ghcr.io/agentflocks/flocks:latest

Windows PowerShell

docker run -d `
  --name flocks `
  -p 5173:5173 `
  --shm-size 4gb `
  -v "${env:USERPROFILE}\.flocks:/home/flocks/.flocks" `
  ghcr.io/agentflocks/flocks:latest

EXPOSE in the image only documents container ports. You still need -p 5173:5173 to access the service from the host browser.

On machines in mainland China, you can configure uv to use a local PyPI mirror for faster package downloads.

Create ~/.config/uv/uv.toml with:

[[index]]
url = "https://pypi.tuna.tsinghua.edu.cn/simple"

[[index]]
url = "https://pypi.org/simple"
default = true

Docker registry mirror in China

• 1ms GHCR: docker pull ghcr.1ms.run/agentflocks/flocks:latest
• dockerproxy GHCR: docker pull ghcr.dockerproxy.net/agentflocks/flocks:latest
• gh-proxy prefix: docker pull docker.gh-proxy.com/ghcr.io/agentflocks/flocks:latest
• milu GHCR: docker pull ghcr.milu.moe/agentflocks/flocks:latest
• NJU GHCR: docker pull ghcr.nju.edu.cn/agentflocks/flocks:latest

Permission issues for /home/flocks/.flocks after startup:

-v "$HOME/.flocks:/home/flocks/.flocks:Z" \

OR

docker run --rm --entrypoint id ghcr.io/agentflocks/flocks
# example result: uid=1001(flocks) gid=1001(flocks) 组=1001(flocks)
sudo chown -R <uid>:<gid> ~/.flocks
# example: sudo chown -R 1001:1001 ~/.flocks

flocks start --host 0.0.0.0

If remote access from a virtual machine fails, please specify the host as the virtual machine's IP.

The WebUI and API share the same service address and port. API requests use the same-origin /api path, keeping browser cookies and SSE on a single origin for LAN access and reverse-proxy deployments.

Only enable direct browser-to-backend URLs when you explicitly need them:

FLOCKS_WEBUI_DIRECT_BACKEND_URLS=1 \
flocks start --server-host 0.0.0.0 --webui-host 0.0.0.0

Since the local-account update, every HTTP path is protected by default — only the WebUI bootstrap pages (/, /auth/*), static assets, and IM platform webhooks (/api/channel/{channel_id}/webhook) are public.

Initial setup:

1. Open the WebUI and complete the bootstrap-admin flow to create the single admin account.
2. The browser session cookie (flocks_session) is enough for the WebUI; no extra steps are required.

Non-browser clients (TUI, SDKs, scripts):

• All non-browser clients, including local loopback clients, must present an API token. The token lives in ~/.flocks/config/.secret.json under the secret id server_api_token.

  On the server, generate (or rotate) the token — it is persisted on the server's local secret store:

  flocks admin generate-api-token        # prints token; stores under server_api_token

  On each remote client, store the same token value into the client's own secret file (so the client SDK / TUI can attach it automatically):

  flocks admin set-api-token --token <token-from-server>

  Or attach it directly per request via either header:

  Authorization: Bearer <token>
  X-Flocks-API-Token: <token>
  

  Smoke test:

  curl -H "Authorization: Bearer <token>" https://flocks.example.com/api/health

  Query the live runtime status of a specific session:

  curl -H "Authorization: Bearer <token>" \
    https://flocks.example.com/api/session/<sessionID>/status

  status.type is one of idle, queued, busy, retry, compacting, or dreaming. Automation clients can use isProcessing to determine whether accepted work is still running or waiting. idle only means that the session is currently inactive; it does not indicate whether the previous run succeeded.

Reverse-proxy deployments:

• Always set X-Forwarded-For on the proxy. Without it, any direct loopback request would be auto-elevated to admin. The middleware intentionally refuses to trust loopback when this header is absent and a proxy is in front.
• For HTTPS termination, also forward X-Forwarded-Proto: https so that the secure-cookie flag is set correctly.
• Prefer same-origin proxying for browser traffic: keep the WebUI on / and route backend traffic through /api (and /event if needed). Do not set VITE_API_BASE_URL in reverse-proxy deployments unless you intentionally want the browser to bypass the proxy and talk to the backend origin directly.
• For SSE endpoints, disable proxy buffering and keep HTTP/1.1 enabled.

Recovery / lost password:

• Run flocks admin generate-one-time-password on the host. The admin account is then forced into must_reset_password=true; the next WebUI login is redirected to the change-password page. All non-browser endpoints return 403 in that state, so do not run this against an account that automation depends on without coordination.

Orphan sessions (CLI / background / inbound channels):

• Sessions created without an auth context (CLI commands, background tasks, inbound IM-channel dispatchers) leave owner_user_id empty. The bootstrap admin still sees them, but a later-added member account would not. Backfill ownership with:

  flocks admin reassign-orphan-sessions --username admin --dry-run   # preview
  flocks admin reassign-orphan-sessions --username admin             # apply

  The command summarises scanned / orphaned / reassigned / failed counts; a non-zero failed exits with code 2 so CI / scripts can detect partial-write situations and re-run after fixing the underlying cause (typically a transient storage error).

Scan the QR code with WeChat to join our official discussion group.

See CONTRIBUTING.md for development setup, coding standards, testing expectations, and Pull Request guidelines.

Apache License 2.0