* feat: streaming container mode, IPC messaging, agent teams support
Major architectural shift from single-shot container runs to long-lived
streaming containers with IPC-based message injection.
- Agent runner: query loop with AsyncIterable prompt to keep stdin open
for agent teams (fixes isSingleUserTurn premature shutdown)
- New standalone stdio MCP server (ipc-mcp-stdio.ts) inheritable by
subagents, with send_message and schedule_task tools
- Streaming output: parse OUTPUT_START/END markers in real-time, send
results to WhatsApp as they arrive
- IPC file-based messaging: host writes to ipc/{group}/input/, agent
polls for follow-up messages without respawning containers
- Per-group settings.json with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
- SDK bumped to 0.2.34 for TeamCreate tool support
- Container idle timeout (30min) with _close sentinel for shutdown
- Orphaned container cleanup on startup
- alwaysRespond flag for groups that skip trigger pattern check
- Uncaught exception/rejection handlers with timestamps in logger
- Combined SDK documentation into single deep dive reference
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* chore: remove unused ipc-mcp.ts (replaced by ipc-mcp-stdio.ts)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: clarify agent communication model in docs and tool descriptions
- CLAUDE.md (main + global): split communication instructions into
"responding to messages" vs "scheduled tasks" sections
- send_message tool: note that scheduled task output is not sent to user
- Remove structured output (outputFormat) — not needed with current flow
- Regular output is sent to WhatsApp; scheduled task output is only logged
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* chore: ignore dynamic group data while preserving base structure
Only track groups/main/CLAUDE.md and groups/global/CLAUDE.md. All other
group directories and files are ignored to prevent tracking user-specific
session data.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: resolve critical bugs in streaming container mode
Bug 1 (scheduled task hang): Task scheduler now passes onOutput callback
with idle timer that writes _close sentinel after IDLE_TIMEOUT, so
containers exit cleanly instead of blocking queue slots for 30 minutes.
Scheduled tasks stay alive for interactive follow-up via IPC.
Bug 2 (timeout disabled): Remove resetTimeout() from stderr handler.
SDK writes debug logs continuously, resetting the timer on every line.
Timeout now only resets on actual output markers in stdout.
Bug 3 (trigger bypass): Piped messages in startMessageLoop now check
trigger pattern for non-main groups. Non-trigger messages accumulate in
DB and are pulled as context via getMessagesSince when a trigger arrives.
Bug 7 (non-atomic IPC writes): GroupQueue.sendMessage uses temp file +
rename for atomic writes, matching ipc-mcp-stdio.ts pattern.
Also: flip isVerbose back to false (debug leftover), add isScheduledTask
to host-side ContainerInput interface.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: idle timer not starting + scheduled task groupFolder missing
Two bugs that prevented the scheduled task idle timeout fix from working:
1. onOutput was only called when parsed.result !== null, but session
update markers have result: null. The idle timer never started for
"silent" query completions, leaving containers parked at
waitForIpcMessage until hard timeout.
2. Scheduler's onProcess callback didn't pass groupFolder to
queue.registerProcess, so closeStdin no-oped (groupFolder was null).
The _close sentinel was never written even when the idle timer fired.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: duplicate messages and timestamp rollback in piping path
Two bugs introduced by the trigger context accumulation change:
1. processGroupMessages didn't advance lastAgentTimestamp until after
the container finished. The piping path's getMessagesSince(lastAgent
Timestamp) re-fetched messages already sent as the initial prompt,
causing duplicates.
2. processGroupMessages overwrote lastAgentTimestamp with the original
batch timestamp on completion, rolling back any advancement made by
the piping path while the container was running.
Fix: advance lastAgentTimestamp immediately after building the prompt,
before starting the container. This matches the piping path behavior
and eliminates both the overlap and the rollback.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: container idles 30 extra minutes after _close during query
When _close was detected during pollIpcDuringQuery, it was consumed
(deleted) and stream.end() was called. But after runQuery returned,
main() still emitted a session-update marker (resetting the host's idle
timer) and called waitForIpcMessage (which polled forever since _close
was already gone). The container had to wait for a second _close.
Fix: runQuery now returns closedDuringQuery. When true, main() skips
the session-update marker and waitForIpcMessage, exiting immediately.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: resume branching, internal tags, and output forwarding
- Fix resume branching: pass resumeSessionAt with last assistant UUID
to anchor each query loop resume to the correct conversation tree
position. Prevents agent responses landing on invisible branches
when agent teams subagents create parallel JSONL entries.
- Add <internal> tag stripping: agent can wrap internal reasoning in
<internal> tags which are logged but not sent to WhatsApp. Prevents
duplicate messages and internal monologue reaching users.
- Forward scheduled task output: scheduled tasks now send result text
to WhatsApp (with <internal> stripping), matching regular message
behavior. No more special-case instructions.
- Update Communication guidance in CLAUDE.md: simplified to "your
output is sent to the user or group" with soft guidance on
<internal> tags and send_message usage.
- Add messaging behavior docs to schedule_task tool: prompts the
scheduling agent to include guidance on whether the task should
always/conditionally/never message the user.
- Mount security: containerPath now optional, defaults to basename
of hostPath.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: cursor rollback on error, flush guard, verbose logging
- Roll back lastAgentTimestamp on container error so retries can
re-process the messages instead of silently losing them.
- Add guard flag to flushOutgoingQueue to prevent duplicate sends
from concurrent flushes during rapid WA reconnects.
- Revert isVerbose from hardcoded false back to env-based check
(LOG_LEVEL=debug|trace).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: orphan container cleanup was silently failing
The startup cleanup used `container ls --format {{.Names}}` which is
Docker Go-template syntax. Apple Container only supports `--format json`
or `--format table`. The command errored with exit code 64, but the
catch block silently swallowed it — orphan containers were never cleaned
up on restart.
Fixed to use `--format json` and parse `configuration.id` from the
JSON output. Also filters by `status: running` and logs a warning on
failure instead of silently catching.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* docs: add Discord badge and community section
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: idle timer reset on null results and flush queue message loss
- Only reset idle timer on actual results (non-null), not session-update
markers. Prevents containers staying alive 30 extra minutes after the
agent finishes work.
- flushOutgoingQueue now uses shift() instead of splice(0) so unattempted
messages stay in the queue if an unexpected error bails the loop.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* docs: add Agent Swarms to README
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: update Telegram skill for current architecture
Rewrite integration instructions to match the per-group queue/SQLite
architecture: remove onMessage callback pattern (store to DB, let
message loop pick up), fix startSchedulerLoop signature, add
TELEGRAM_ONLY service startup, SQLite registration, data/env/env sync,
@mention-to-trigger translation, and BotFather group privacy docs.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: Telegram skill message chunking, media placeholders, chat discovery
- Split long messages at Telegram's 4096 char limit to prevent silent
send failures
- Store placeholder text for non-text messages (photos, voice, stickers,
etc.) so the agent knows media was sent
- Update getAvailableGroups filter to include tg: chats so the agent can
discover and register Telegram chats via IPC
- Fix removal step numbering
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* docs: update REQUIREMENTS.md and SPEC.md for SQLite architecture
- Replace all registered_groups.json / sessions.json / router_state.json
references with SQLite equivalents
- Fix CONTAINER_TIMEOUT default (300000 → 1800000)
- Add missing config exports (IDLE_TIMEOUT, MAX_CONCURRENT_CONTAINERS)
- Update folder structure: add missing src files (logger, group-queue,
mount-security), remove non-existent utils.ts, list all skills
- Fix agent-runner entry (ipc-mcp.ts → ipc-mcp-stdio.ts)
- Update startup sequence to reflect per-group queue architecture
- Fix env mounting description (data/env/env, not extracted vars)
- Update troubleshooting to use sqlite3 commands
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* docs: fix README architecture description, revert SPEC.md env error
- README: update architecture blurb to mention per-group queue, add
group-queue.ts to key files, update file descriptions
- SPEC.md: restore correct credential filtering description (only auth
vars are extracted from .env, not the full file)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
484 lines
15 KiB
Markdown
484 lines
15 KiB
Markdown
---
|
|
name: setup
|
|
description: Run initial NanoClaw setup. Use when user wants to install dependencies, authenticate WhatsApp, register their main channel, or start the background services. Triggers on "setup", "install", "configure nanoclaw", or first-time setup requests.
|
|
---
|
|
|
|
# NanoClaw Setup
|
|
|
|
Run all commands automatically. Only pause when user action is required (scanning QR codes).
|
|
|
|
**UX Note:** When asking the user questions, prefer using the `AskUserQuestion` tool instead of just outputting text. This integrates with Claude's built-in question/answer system for a better experience.
|
|
|
|
## 1. Install Dependencies
|
|
|
|
```bash
|
|
npm install
|
|
```
|
|
|
|
## 2. Install Container Runtime
|
|
|
|
First, detect the platform and check what's available:
|
|
|
|
```bash
|
|
echo "Platform: $(uname -s)"
|
|
which container && echo "Apple Container: installed" || echo "Apple Container: not installed"
|
|
which docker && docker info >/dev/null 2>&1 && echo "Docker: installed and running" || echo "Docker: not installed or not running"
|
|
```
|
|
|
|
### If NOT on macOS (Linux, etc.)
|
|
|
|
Apple Container is macOS-only. Use Docker instead.
|
|
|
|
Tell the user:
|
|
> You're on Linux, so we'll use Docker for container isolation. Let me set that up now.
|
|
|
|
**Use the `/convert-to-docker` skill** to convert the codebase to Docker, then continue to Section 3.
|
|
|
|
### If on macOS
|
|
|
|
**If Apple Container is already installed:** Continue to Section 3.
|
|
|
|
**If Apple Container is NOT installed:** Ask the user:
|
|
> NanoClaw needs a container runtime for isolated agent execution. You have two options:
|
|
>
|
|
> 1. **Apple Container** (default) - macOS-native, lightweight, designed for Apple silicon
|
|
> 2. **Docker** - Cross-platform, widely used, works on macOS and Linux
|
|
>
|
|
> Which would you prefer?
|
|
|
|
#### Option A: Apple Container
|
|
|
|
Tell the user:
|
|
> Apple Container is required for running agents in isolated environments.
|
|
>
|
|
> 1. Download the latest `.pkg` from https://github.com/apple/container/releases
|
|
> 2. Double-click to install
|
|
> 3. Run `container system start` to start the service
|
|
>
|
|
> Let me know when you've completed these steps.
|
|
|
|
Wait for user confirmation, then verify:
|
|
|
|
```bash
|
|
container system start
|
|
container --version
|
|
```
|
|
|
|
**Note:** NanoClaw automatically starts the Apple Container system when it launches, so you don't need to start it manually after reboots.
|
|
|
|
#### Option B: Docker
|
|
|
|
Tell the user:
|
|
> You've chosen Docker. Let me set that up now.
|
|
|
|
**Use the `/convert-to-docker` skill** to convert the codebase to Docker, then continue to Section 3.
|
|
|
|
## 3. Configure Claude Authentication
|
|
|
|
Ask the user:
|
|
> Do you want to use your **Claude subscription** (Pro/Max) or an **Anthropic API key**?
|
|
|
|
### Option 1: Claude Subscription (Recommended)
|
|
|
|
Tell the user:
|
|
> Open another terminal window and run:
|
|
> ```
|
|
> claude setup-token
|
|
> ```
|
|
> A browser window will open for you to log in. Once authenticated, the token will be displayed in your terminal. Either:
|
|
> 1. Paste it here and I'll add it to `.env` for you, or
|
|
> 2. Add it to `.env` yourself as `CLAUDE_CODE_OAUTH_TOKEN=<your-token>`
|
|
|
|
If they give you the token, add it to `.env`:
|
|
|
|
```bash
|
|
echo "CLAUDE_CODE_OAUTH_TOKEN=<token>" > .env
|
|
```
|
|
|
|
### Option 2: API Key
|
|
|
|
Ask if they have an existing key to copy or need to create one.
|
|
|
|
**Copy existing:**
|
|
```bash
|
|
grep "^ANTHROPIC_API_KEY=" /path/to/source/.env > .env
|
|
```
|
|
|
|
**Create new:**
|
|
```bash
|
|
echo 'ANTHROPIC_API_KEY=' > .env
|
|
```
|
|
|
|
Tell the user to add their key from https://console.anthropic.com/
|
|
|
|
**Verify:**
|
|
```bash
|
|
KEY=$(grep "^ANTHROPIC_API_KEY=" .env | cut -d= -f2)
|
|
[ -n "$KEY" ] && echo "API key configured: ${KEY:0:10}...${KEY: -4}" || echo "Missing"
|
|
```
|
|
|
|
## 4. Build Container Image
|
|
|
|
Build the NanoClaw agent container:
|
|
|
|
```bash
|
|
./container/build.sh
|
|
```
|
|
|
|
This creates the `nanoclaw-agent:latest` image with Node.js, Chromium, Claude Code CLI, and agent-browser.
|
|
|
|
Verify the build succeeded by running a simple test (this auto-detects which runtime you're using):
|
|
|
|
```bash
|
|
if which docker >/dev/null 2>&1 && docker info >/dev/null 2>&1; then
|
|
echo '{}' | docker run -i --entrypoint /bin/echo nanoclaw-agent:latest "Container OK" || echo "Container build failed"
|
|
else
|
|
echo '{}' | container run -i --entrypoint /bin/echo nanoclaw-agent:latest "Container OK" || echo "Container build failed"
|
|
fi
|
|
```
|
|
|
|
## 5. WhatsApp Authentication
|
|
|
|
**USER ACTION REQUIRED**
|
|
|
|
**IMPORTANT:** Run this command in the **foreground**. The QR code is multi-line ASCII art that must be displayed in full. Do NOT run in background or truncate the output.
|
|
|
|
Tell the user:
|
|
> A QR code will appear below. On your phone:
|
|
> 1. Open WhatsApp
|
|
> 2. Tap **Settings → Linked Devices → Link a Device**
|
|
> 3. Scan the QR code
|
|
|
|
Run with a long Bash tool timeout (120000ms) so the user has time to scan. Do NOT use the `timeout` shell command (it's not available on macOS).
|
|
|
|
```bash
|
|
npm run auth
|
|
```
|
|
|
|
Wait for the script to output "Successfully authenticated" then continue.
|
|
|
|
If it says "Already authenticated", skip to the next step.
|
|
|
|
## 6. Configure Assistant Name and Main Channel
|
|
|
|
This step configures three things at once: the trigger word, the main channel type, and the main channel selection.
|
|
|
|
### 6a. Ask for trigger word
|
|
|
|
Ask the user:
|
|
> What trigger word do you want to use? (default: `Andy`)
|
|
>
|
|
> In group chats, messages starting with `@TriggerWord` will be sent to Claude.
|
|
> In your main channel (and optionally solo chats), no prefix is needed — all messages are processed.
|
|
|
|
Store their choice for use in the steps below.
|
|
|
|
### 6b. Explain security model and ask about main channel type
|
|
|
|
**Use the AskUserQuestion tool** to present this:
|
|
|
|
> **Important: Your "main" channel is your admin control portal.**
|
|
>
|
|
> The main channel has elevated privileges:
|
|
> - Can see messages from ALL other registered groups
|
|
> - Can manage and delete tasks across all groups
|
|
> - Can write to global memory that all groups can read
|
|
> - Has read-write access to the entire NanoClaw project
|
|
>
|
|
> **Recommendation:** Use your personal "Message Yourself" chat or a solo WhatsApp group as your main channel. This ensures only you have admin control.
|
|
>
|
|
> **Question:** Which setup will you use for your main channel?
|
|
>
|
|
> Options:
|
|
> 1. Personal chat (Message Yourself) - Recommended
|
|
> 2. Solo WhatsApp group (just me)
|
|
> 3. Group with other people (I understand the security implications)
|
|
|
|
If they choose option 3, ask a follow-up:
|
|
|
|
> You've chosen a group with other people. This means everyone in that group will have admin privileges over NanoClaw.
|
|
>
|
|
> Are you sure you want to proceed? The other members will be able to:
|
|
> - Read messages from your other registered chats
|
|
> - Schedule and manage tasks
|
|
> - Access any directories you've mounted
|
|
>
|
|
> Options:
|
|
> 1. Yes, I understand and want to proceed
|
|
> 2. No, let me use a personal chat or solo group instead
|
|
|
|
### 6c. Register the main channel
|
|
|
|
First build, then start the app briefly to connect to WhatsApp and sync group metadata. Use the Bash tool's timeout parameter (15000ms) — do NOT use the `timeout` shell command (it's not available on macOS). The app will be killed when the timeout fires, which is expected.
|
|
|
|
```bash
|
|
npm run build
|
|
```
|
|
|
|
Then run briefly (set Bash tool timeout to 15000ms):
|
|
```bash
|
|
npm run dev
|
|
```
|
|
|
|
**For personal chat** (they chose option 1):
|
|
|
|
Personal chats are NOT synced to the database on startup — only groups are. Instead, ask the user for their phone number (with country code, no + or spaces, e.g. `14155551234`), then construct the JID as `{number}@s.whatsapp.net`.
|
|
|
|
**For group** (they chose option 2 or 3):
|
|
|
|
Groups are synced on startup via `groupFetchAllParticipating`. Query the database for recent groups:
|
|
```bash
|
|
sqlite3 store/messages.db "SELECT jid, name FROM chats WHERE jid LIKE '%@g.us' AND jid != '__group_sync__' ORDER BY last_message_time DESC LIMIT 40"
|
|
```
|
|
|
|
Show only the **10 most recent** group names to the user and ask them to pick one. If they say their group isn't in the list, show the next batch from the results you already have. If they tell you the group name directly, look it up:
|
|
```bash
|
|
sqlite3 store/messages.db "SELECT jid, name FROM chats WHERE name LIKE '%GROUP_NAME%' AND jid LIKE '%@g.us'"
|
|
```
|
|
|
|
### 6d. Write the configuration
|
|
|
|
Once you have the JID, configure it. Use the assistant name from step 6a.
|
|
|
|
For personal chats (solo, no prefix needed), set `requiresTrigger` to `false`:
|
|
|
|
```json
|
|
{
|
|
"JID_HERE": {
|
|
"name": "main",
|
|
"folder": "main",
|
|
"trigger": "@ASSISTANT_NAME",
|
|
"added_at": "CURRENT_ISO_TIMESTAMP",
|
|
"requiresTrigger": false
|
|
}
|
|
}
|
|
```
|
|
|
|
For groups, keep `requiresTrigger` as `true` (default).
|
|
|
|
Write to the database directly by creating a temporary registration script, or write `data/registered_groups.json` which will be auto-migrated on first run:
|
|
|
|
```bash
|
|
mkdir -p data
|
|
```
|
|
|
|
Then write `data/registered_groups.json` with the correct JID, trigger, and timestamp.
|
|
|
|
If the user chose a name other than `Andy`, also update:
|
|
1. `groups/global/CLAUDE.md` - Change "# Andy" and "You are Andy" to the new name
|
|
2. `groups/main/CLAUDE.md` - Same changes at the top
|
|
|
|
Ensure the groups folder exists:
|
|
```bash
|
|
mkdir -p groups/main/logs
|
|
```
|
|
|
|
## 7. Configure External Directory Access (Mount Allowlist)
|
|
|
|
Ask the user:
|
|
> Do you want the agent to be able to access any directories **outside** the NanoClaw project?
|
|
>
|
|
> Examples: Git repositories, project folders, documents you want Claude to work on.
|
|
>
|
|
> **Note:** This is optional. Without configuration, agents can only access their own group folders.
|
|
|
|
If **no**, create an empty allowlist to make this explicit:
|
|
|
|
```bash
|
|
mkdir -p ~/.config/nanoclaw
|
|
cat > ~/.config/nanoclaw/mount-allowlist.json << 'EOF'
|
|
{
|
|
"allowedRoots": [],
|
|
"blockedPatterns": [],
|
|
"nonMainReadOnly": true
|
|
}
|
|
EOF
|
|
echo "Mount allowlist created - no external directories allowed"
|
|
```
|
|
|
|
Skip to the next step.
|
|
|
|
If **yes**, ask follow-up questions:
|
|
|
|
### 7a. Collect Directory Paths
|
|
|
|
Ask the user:
|
|
> Which directories do you want to allow access to?
|
|
>
|
|
> You can specify:
|
|
> - A parent folder like `~/projects` (allows access to anything inside)
|
|
> - Specific paths like `~/repos/my-app`
|
|
>
|
|
> List them one per line, or give me a comma-separated list.
|
|
|
|
For each directory they provide, ask:
|
|
> Should `[directory]` be **read-write** (agents can modify files) or **read-only**?
|
|
>
|
|
> Read-write is needed for: code changes, creating files, git commits
|
|
> Read-only is safer for: reference docs, config examples, templates
|
|
|
|
### 7b. Configure Non-Main Group Access
|
|
|
|
Ask the user:
|
|
> Should **non-main groups** (other WhatsApp chats you add later) be restricted to **read-only** access even if read-write is allowed for the directory?
|
|
>
|
|
> Recommended: **Yes** - this prevents other groups from modifying files even if you grant them access to a directory.
|
|
|
|
### 7c. Create the Allowlist
|
|
|
|
Create the allowlist file based on their answers:
|
|
|
|
```bash
|
|
mkdir -p ~/.config/nanoclaw
|
|
```
|
|
|
|
Then write the JSON file. Example for a user who wants `~/projects` (read-write) and `~/docs` (read-only) with non-main read-only:
|
|
|
|
```bash
|
|
cat > ~/.config/nanoclaw/mount-allowlist.json << 'EOF'
|
|
{
|
|
"allowedRoots": [
|
|
{
|
|
"path": "~/projects",
|
|
"allowReadWrite": true,
|
|
"description": "Development projects"
|
|
},
|
|
{
|
|
"path": "~/docs",
|
|
"allowReadWrite": false,
|
|
"description": "Reference documents"
|
|
}
|
|
],
|
|
"blockedPatterns": [],
|
|
"nonMainReadOnly": true
|
|
}
|
|
EOF
|
|
```
|
|
|
|
Verify the file:
|
|
|
|
```bash
|
|
cat ~/.config/nanoclaw/mount-allowlist.json
|
|
```
|
|
|
|
Tell the user:
|
|
> Mount allowlist configured. The following directories are now accessible:
|
|
> - `~/projects` (read-write)
|
|
> - `~/docs` (read-only)
|
|
>
|
|
> **Security notes:**
|
|
> - Sensitive paths (`.ssh`, `.gnupg`, `.aws`, credentials) are always blocked
|
|
> - This config file is stored outside the project, so agents cannot modify it
|
|
> - Changes require restarting the NanoClaw service
|
|
>
|
|
> To grant a group access to a directory, add it to their config in `data/registered_groups.json`:
|
|
> ```json
|
|
> "containerConfig": {
|
|
> "additionalMounts": [
|
|
> { "hostPath": "~/projects/my-app" }
|
|
> ]
|
|
> }
|
|
> ```
|
|
> The folder appears inside the container at `/workspace/extra/<folder-name>` (derived from the last segment of the path). Add `"readonly": false` for write access, or `"containerPath": "custom-name"` to override the default name.
|
|
|
|
## 8. Configure launchd Service
|
|
|
|
Generate the plist file with correct paths automatically:
|
|
|
|
```bash
|
|
NODE_PATH=$(which node)
|
|
PROJECT_PATH=$(pwd)
|
|
HOME_PATH=$HOME
|
|
|
|
cat > ~/Library/LaunchAgents/com.nanoclaw.plist << EOF
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
|
|
<plist version="1.0">
|
|
<dict>
|
|
<key>Label</key>
|
|
<string>com.nanoclaw</string>
|
|
<key>ProgramArguments</key>
|
|
<array>
|
|
<string>${NODE_PATH}</string>
|
|
<string>${PROJECT_PATH}/dist/index.js</string>
|
|
</array>
|
|
<key>WorkingDirectory</key>
|
|
<string>${PROJECT_PATH}</string>
|
|
<key>RunAtLoad</key>
|
|
<true/>
|
|
<key>KeepAlive</key>
|
|
<true/>
|
|
<key>EnvironmentVariables</key>
|
|
<dict>
|
|
<key>PATH</key>
|
|
<string>/usr/local/bin:/usr/bin:/bin:${HOME_PATH}/.local/bin</string>
|
|
<key>HOME</key>
|
|
<string>${HOME_PATH}</string>
|
|
</dict>
|
|
<key>StandardOutPath</key>
|
|
<string>${PROJECT_PATH}/logs/nanoclaw.log</string>
|
|
<key>StandardErrorPath</key>
|
|
<string>${PROJECT_PATH}/logs/nanoclaw.error.log</string>
|
|
</dict>
|
|
</plist>
|
|
EOF
|
|
|
|
echo "Created launchd plist with:"
|
|
echo " Node: ${NODE_PATH}"
|
|
echo " Project: ${PROJECT_PATH}"
|
|
```
|
|
|
|
Build and start the service:
|
|
|
|
```bash
|
|
npm run build
|
|
mkdir -p logs
|
|
launchctl load ~/Library/LaunchAgents/com.nanoclaw.plist
|
|
```
|
|
|
|
Verify it's running:
|
|
```bash
|
|
launchctl list | grep nanoclaw
|
|
```
|
|
|
|
## 9. Test
|
|
|
|
Tell the user (using the assistant name they configured):
|
|
> Send `@ASSISTANT_NAME hello` in your registered chat.
|
|
>
|
|
> **Tip:** In your main channel, you don't need the `@` prefix — just send `hello` and the agent will respond.
|
|
|
|
Check the logs:
|
|
```bash
|
|
tail -f logs/nanoclaw.log
|
|
```
|
|
|
|
The user should receive a response in WhatsApp.
|
|
|
|
## Troubleshooting
|
|
|
|
**Service not starting**: Check `logs/nanoclaw.error.log`
|
|
|
|
**Container agent fails with "Claude Code process exited with code 1"**:
|
|
- Ensure the container runtime is running:
|
|
- Apple Container: `container system start`
|
|
- Docker: `docker info` (start Docker Desktop on macOS, or `sudo systemctl start docker` on Linux)
|
|
- Check container logs: `cat groups/main/logs/container-*.log | tail -50`
|
|
|
|
**No response to messages**:
|
|
- Verify the trigger pattern matches (e.g., `@AssistantName` at start of message)
|
|
- Main channel doesn't require a prefix — all messages are processed
|
|
- Personal/solo chats with `requiresTrigger: false` also don't need a prefix
|
|
- Check that the chat JID is in the database: `sqlite3 store/messages.db "SELECT * FROM registered_groups"`
|
|
- Check `logs/nanoclaw.log` for errors
|
|
|
|
**WhatsApp disconnected**:
|
|
- The service will show a macOS notification
|
|
- Run `npm run auth` to re-authenticate
|
|
- Restart the service: `launchctl kickstart -k gui/$(id -u)/com.nanoclaw`
|
|
|
|
**Unload service**:
|
|
```bash
|
|
launchctl unload ~/Library/LaunchAgents/com.nanoclaw.plist
|
|
```
|