docs: address search entry review feedback
This commit is contained in:
chengyongru
Xubin Ren
@@ -13,7 +13,7 @@ edge cases.
|
||||
| Use the browser workbench | [AI agent WebUI](./ai-agent-webui.md) |
|
||||
| Run long-running tasks | [Long-running AI agent](./long-running-ai-agent.md) |
|
||||
| Add memory | [AI agent memory](./ai-agent-memory.md) |
|
||||
| Deploy a gateway | [Deploy an AI agent gateway](./deploy-ai-agent-gateway.md) |
|
||||
| Deploy a gateway | [Deploy a long-running nanobot AI agent gateway](./deploy-nanobot-gateway.md) |
|
||||
|
||||
## Connect and integrate
|
||||
|
||||
|
||||
@@ -60,7 +60,8 @@ sessions for longer work.
|
||||
## Security notes
|
||||
|
||||
- Do not store API keys directly in shared files; use environment variables.
|
||||
- Keep chat app `allowFrom` lists narrow.
|
||||
- Prefer chat app pairing for first setup. Use `allowFrom` only for static
|
||||
allowlists, and keep those lists narrow.
|
||||
- Enable workspace restriction before exposing file or shell tools to other
|
||||
users.
|
||||
- Use a separate workspace for experiments that can modify files.
|
||||
|
||||
@@ -9,7 +9,7 @@ messages, runs the agent, and sends replies back to the same channel.
|
||||
- a working local agent
|
||||
- one enabled chat channel
|
||||
- a running gateway
|
||||
- a narrow access-control rule for the first test user
|
||||
- a pairing-based approval flow or a narrow static allowlist
|
||||
|
||||
## When to use this
|
||||
|
||||
@@ -39,31 +39,37 @@ Every channel follows the same pattern:
|
||||
|
||||
1. Get the platform token, login state, webhook, or mailbox credentials.
|
||||
2. Merge the channel snippet into `~/.nanobot/config.json`.
|
||||
3. Keep access narrow with `allowFrom`, `allowChannels`, or pairing.
|
||||
4. Check status:
|
||||
3. Prefer pairing for DM-capable channels: omit `allowFrom`, then approve the
|
||||
first DM's pairing code.
|
||||
4. For channels without pairing, such as Email, keep access narrow with
|
||||
`allowFrom` or platform-specific allow lists.
|
||||
5. Check status:
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
```
|
||||
|
||||
5. Start the gateway:
|
||||
6. Start the gateway:
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
6. Send a test message from an allowed account.
|
||||
7. Send a test DM, approve the pairing code when prompted, then send the test
|
||||
message again.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Keep the gateway running as a service for always-on chat apps.
|
||||
- Use mention-only group policies before opening a bot to busy channels.
|
||||
- Use one channel at a time while debugging.
|
||||
- Prefer DMs for first tests; group chats add permissions and routing behavior.
|
||||
- Prefer DMs for first tests; pairing only works in DMs, and group chats add
|
||||
permissions and routing behavior.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Do not use `allowFrom: ["*"]` outside an intentional sandbox.
|
||||
- Prefer pairing or explicit allowlists; do not use `allowFrom: ["*"]` outside
|
||||
an intentional sandbox.
|
||||
- Rotate bot tokens if they are pasted into logs or shared files.
|
||||
- Review file, shell, and web tool access before inviting other users.
|
||||
|
||||
@@ -71,6 +77,8 @@ nanobot gateway
|
||||
|
||||
- If `nanobot channels status` does not show the channel, the config key or
|
||||
optional dependency is likely missing.
|
||||
- If the first DM returns a pairing code, approve it with
|
||||
`/pairing approve <code>` before expecting normal replies.
|
||||
- If messages do not arrive, run `nanobot gateway --verbose` and compare
|
||||
platform credentials, event permissions, and allow lists.
|
||||
- If group replies are unexpected, review that channel's group policy.
|
||||
|
||||
@@ -34,16 +34,16 @@ with ones you control:
|
||||
"modelPresets": {
|
||||
"fast": {
|
||||
"label": "Fast",
|
||||
"provider": "openrouter",
|
||||
"model": "anthropic/claude-sonnet-4.5",
|
||||
"provider": "primary-provider",
|
||||
"model": "primary-model-id",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"deep": {
|
||||
"label": "Deep",
|
||||
"provider": "anthropic",
|
||||
"model": "claude-sonnet-4-5",
|
||||
"provider": "fallback-provider",
|
||||
"model": "fallback-model-id",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 200000,
|
||||
"temperature": 0.1
|
||||
@@ -59,6 +59,9 @@ with ones you control:
|
||||
```
|
||||
|
||||
String entries in `fallbackModels` are preset names, not raw model IDs.
|
||||
Replace the placeholder model IDs with currently supported model IDs from your
|
||||
provider. The [Provider Cookbook](../provider-cookbook.md) has concrete recipes
|
||||
for common providers.
|
||||
|
||||
## Production notes
|
||||
|
||||
|
||||
@@ -1,68 +0,0 @@
|
||||
# How to Deploy a Long-Running AI Agent Gateway with nanobot
|
||||
|
||||
The nanobot gateway is the long-running process behind WebUI sessions, chat app
|
||||
messages, automations, local triggers, and WebSocket delivery.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a configured nanobot instance
|
||||
- a gateway process that survives terminal exits
|
||||
- a service or container deployment path
|
||||
|
||||
## When to use this
|
||||
|
||||
Deploy the gateway when nanobot must keep receiving messages or running
|
||||
automations after a one-off CLI command ends.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Start the gateway in the foreground:
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
For browser usage, the WebUI launcher can manage the gateway:
|
||||
|
||||
```bash
|
||||
nanobot webui --background
|
||||
```
|
||||
|
||||
For server usage, configure Docker, systemd, or macOS LaunchAgent from the
|
||||
deployment reference.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Keep config and workspace paths explicit in services.
|
||||
- Persist `~/.nanobot/config.json`, the workspace, sessions, and memory files.
|
||||
- Use one process per config/workspace pair.
|
||||
- Expose only the ports required by the surfaces you use.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Bind local-only surfaces to `127.0.0.1`.
|
||||
- Add an API key before exposing `nanobot serve` beyond localhost.
|
||||
- Restrict chat app access and workspace tools before putting the gateway on a
|
||||
shared server.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- Use `nanobot status` with the same config/workspace as the service.
|
||||
- Check service logs for provider, port, channel, and permission errors.
|
||||
- If WebUI works locally but not remotely, verify host binding, token settings,
|
||||
and firewall rules.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Deploy nanobot gateway](./deploy-nanobot-gateway.md)
|
||||
- [Deployment](../deployment.md)
|
||||
- [Multiple Instances](../multiple-instances.md)
|
||||
- [WebUI](../webui.md)
|
||||
@@ -1,17 +1,19 @@
|
||||
# How to Deploy nanobot Gateway
|
||||
# How to Deploy a Long-Running nanobot AI Agent Gateway
|
||||
|
||||
The nanobot gateway is the process that keeps WebUI, chat apps, automations,
|
||||
heartbeat jobs, Dream, and WebSocket delivery online.
|
||||
The nanobot gateway is the long-running self-hosted AI agent process that keeps
|
||||
WebUI sessions, chat apps, automations, local triggers, heartbeat jobs, Dream,
|
||||
and WebSocket delivery online.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a verified nanobot config
|
||||
- a gateway process
|
||||
- an optional Docker, systemd, or macOS LaunchAgent deployment
|
||||
- a service or container deployment path with Docker, systemd, or macOS
|
||||
LaunchAgent
|
||||
|
||||
## When to use this
|
||||
|
||||
Use this when nanobot should keep running after a single CLI turn: chat apps,
|
||||
Use this when nanobot should keep running after a single CLI turn. Chat apps,
|
||||
browser sessions, background automations, local triggers, and server-side
|
||||
integrations all depend on a live gateway.
|
||||
|
||||
@@ -69,7 +71,6 @@ nanobot gateway logs
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Deploy a long-running AI agent gateway](./deploy-ai-agent-gateway.md)
|
||||
- [Deployment](../deployment.md)
|
||||
- [Multiple Instances](../multiple-instances.md)
|
||||
- [Configuration](../configuration.md)
|
||||
|
||||
@@ -20,7 +20,6 @@ nanobot agent -m "Hello!"
|
||||
|
||||
- Access to the Discord Developer Portal.
|
||||
- A Discord server where you can invite a bot.
|
||||
- Your Discord user ID.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
@@ -48,7 +47,6 @@ Merge this snippet into `~/.nanobot/config.json`:
|
||||
"discord": {
|
||||
"enabled": true,
|
||||
"token": "YOUR_BOT_TOKEN",
|
||||
"allowFrom": ["YOUR_USER_ID"],
|
||||
"allowChannels": [],
|
||||
"groupPolicy": "mention",
|
||||
"streaming": true
|
||||
@@ -57,6 +55,9 @@ Merge this snippet into `~/.nanobot/config.json`:
|
||||
}
|
||||
```
|
||||
|
||||
Omitting `allowFrom` enables pairing-only mode. A new user should DM the bot
|
||||
first, get a pairing code, and be approved before using the bot in servers.
|
||||
|
||||
Invite the bot with permissions to read history and send messages.
|
||||
|
||||
## Run nanobot gateway
|
||||
@@ -68,8 +69,14 @@ nanobot gateway
|
||||
|
||||
## Test a message
|
||||
|
||||
Send the bot a DM from your allowed account, or mention it in an allowed server
|
||||
channel:
|
||||
Send the bot a DM first. It should return a pairing code. Approve it from a
|
||||
trusted local surface:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
After approval, mention it in an allowed server channel:
|
||||
|
||||
```text
|
||||
@your-bot Hello from Discord
|
||||
@@ -79,13 +86,16 @@ channel:
|
||||
|
||||
- Keep `groupPolicy` as `mention` for first deployment.
|
||||
- Use `allowChannels` for server channels where the bot should operate.
|
||||
- Prefer pairing-only mode for user access; add `allowFrom` only when you want a
|
||||
static allowlist.
|
||||
- Avoid open group behavior in busy channels until session routing is clear.
|
||||
- Review tool access before inviting the bot into shared servers.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If no messages arrive, confirm Message Content intent is enabled.
|
||||
- If server messages are ignored, check `allowFrom`, `allowChannels`, and
|
||||
- If a DM returns a pairing code, approve it before testing normal replies.
|
||||
- If server messages are ignored, check pairing approval, `allowChannels`, and
|
||||
whether the bot was mentioned.
|
||||
- If the bot cannot reply, confirm the invite permissions and channel overrides.
|
||||
|
||||
|
||||
@@ -72,7 +72,8 @@ gateway running long enough for the polling interval to receive it.
|
||||
|
||||
- Use a dedicated mailbox, not your primary personal inbox.
|
||||
- Set `consentGranted` to `false` to fully disable mailbox access.
|
||||
- Keep `allowFrom` narrow; `["*"]` accepts mail from anyone.
|
||||
- Email does not use DM pairing. Keep `allowFrom` narrow; `["*"]` accepts mail
|
||||
from anyone.
|
||||
- Use environment variables for mailbox passwords.
|
||||
- Enable attachment types only when the agent needs them.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ channel, using WebSocket events and the Mattermost REST API.
|
||||
- a Mattermost bot account or token
|
||||
- the `mattermost` channel enabled in nanobot
|
||||
- mention-only group behavior for first deployment
|
||||
- one DM or mention test
|
||||
- one pairing-approved DM or mention test
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -20,8 +20,6 @@ nanobot agent -m "Hello!"
|
||||
|
||||
- A Mattermost server URL.
|
||||
- A bot token or personal access token for the bot account.
|
||||
- Your Mattermost user ID, username, or email depending on
|
||||
`allowFromMatchMode`.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
@@ -42,10 +40,11 @@ Merge this snippet into `~/.nanobot/config.json`:
|
||||
"serverUrl": "https://mattermost.example.com",
|
||||
"token": "YOUR_MATTERMOST_TOKEN",
|
||||
"teamId": "YOUR_TEAM_ID",
|
||||
"allowFromMatchMode": "id",
|
||||
"allowFrom": ["YOUR_USER_ID"],
|
||||
"groupPolicy": "mention",
|
||||
"replyInThread": true
|
||||
"replyInThread": true,
|
||||
"dm": {
|
||||
"policy": "allowlist"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -54,6 +53,10 @@ Merge this snippet into `~/.nanobot/config.json`:
|
||||
`teamId` scopes the channel to a Mattermost team. Keep `groupPolicy` as
|
||||
`mention` for the first test.
|
||||
|
||||
Mattermost DMs are open by default. Setting `dm.policy` to `"allowlist"` with no
|
||||
`dm.allowFrom` entries makes new DM senders receive a pairing code. Approve the
|
||||
code before using the bot normally.
|
||||
|
||||
## Run nanobot gateway
|
||||
|
||||
```bash
|
||||
@@ -63,7 +66,14 @@ nanobot gateway
|
||||
|
||||
## Test a message
|
||||
|
||||
DM the bot account or mention it in a channel where the bot has access:
|
||||
DM the bot account. It should return a pairing code. Approve it from a trusted
|
||||
local surface:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
Then DM the bot again, or mention it in a channel where the bot has access:
|
||||
|
||||
```text
|
||||
@nanobot Hello from Mattermost
|
||||
@@ -72,7 +82,7 @@ DM the bot account or mention it in a channel where the bot has access:
|
||||
## Security notes
|
||||
|
||||
- Store the Mattermost token in an environment variable for deployed services.
|
||||
- Keep `allowFrom` narrow until pairing or team policy is intentional.
|
||||
- Keep `dm.policy` as `"allowlist"` when you want pairing-based approval.
|
||||
- Use mention-only group behavior before opening the bot to busy channels.
|
||||
- Review file and shell tools before inviting broad channel access.
|
||||
|
||||
@@ -80,7 +90,7 @@ DM the bot account or mention it in a channel where the bot has access:
|
||||
|
||||
- If startup logs say `serverUrl and token must be configured`, check the
|
||||
camelCase config keys.
|
||||
- If DMs are ignored, review the `dm` policy and `allowFrom` values.
|
||||
- If DMs are ignored, review the `dm` policy and pairing approval state.
|
||||
- If channel messages are ignored, confirm the bot is mentioned and belongs to
|
||||
the team/channel.
|
||||
- If thread replies are surprising, review `replyInThread` and
|
||||
|
||||
@@ -47,7 +47,9 @@ Start with workspace restriction:
|
||||
- Use environment variables for provider keys, bot tokens, and mailbox
|
||||
passwords.
|
||||
- Keep one workspace per trust boundary.
|
||||
- Use `allowFrom`, pairing, and mention-only group policy for chat apps.
|
||||
- Prefer pairing for DM-capable chat apps, use narrow `allowFrom` lists only
|
||||
when static allowlists are intentional, and keep group policy mention-only at
|
||||
first.
|
||||
- Bind WebUI, WebSocket, and API services to localhost unless remote access is
|
||||
intentional.
|
||||
|
||||
@@ -57,8 +59,8 @@ Start with workspace restriction:
|
||||
- `tools.exec.enable: false` removes shell execution entirely.
|
||||
- HTTP web fetch and HTTP MCP use SSRF protections by default.
|
||||
- Adding broad `tools.ssrfWhitelist` ranges increases exposure.
|
||||
- `allowFrom: ["*"]` means anyone who can reach that channel can talk to the
|
||||
bot.
|
||||
- `allowFrom: ["*"]` bypasses pairing and means anyone who can reach that
|
||||
channel can talk to the bot.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
|
||||
@@ -61,7 +61,8 @@ process running for messages.
|
||||
|
||||
- Bind local-only services to `127.0.0.1` unless you intentionally expose them.
|
||||
- Set an API key before binding the OpenAI-compatible API to a public interface.
|
||||
- Keep `allowFrom` or pairing rules strict on every chat app.
|
||||
- Prefer pairing for DM-capable chat apps, and keep any static `allowFrom`
|
||||
allowlists strict.
|
||||
- Enable `tools.restrictToWorkspace`; on Linux, use the bubblewrap sandbox for
|
||||
shell execution.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ is required for the first working setup.
|
||||
- a Slack app with Socket Mode
|
||||
- a bot token and app-level token
|
||||
- the `slack` channel enabled in nanobot
|
||||
- a DM or mention test from an allowed Slack user
|
||||
- a DM pairing flow and mention test from an approved Slack user
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -19,7 +19,6 @@ nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
- Permission to create a Slack app in a workspace.
|
||||
- Your Slack user ID.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
@@ -49,13 +48,19 @@ Merge this snippet into `~/.nanobot/config.json`:
|
||||
"enabled": true,
|
||||
"botToken": "xoxb-...",
|
||||
"appToken": "xapp-...",
|
||||
"allowFrom": ["YOUR_SLACK_USER_ID"],
|
||||
"groupPolicy": "mention"
|
||||
"groupPolicy": "mention",
|
||||
"dm": {
|
||||
"policy": "allowlist"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Slack DMs are open by default. Setting `dm.policy` to `"allowlist"` with no
|
||||
`dm.allowFrom` entries makes new DM senders receive a pairing code. Approve the
|
||||
code before using the bot normally.
|
||||
|
||||
## Run nanobot gateway
|
||||
|
||||
```bash
|
||||
@@ -65,7 +70,14 @@ nanobot gateway
|
||||
|
||||
## Test a message
|
||||
|
||||
DM the Slack bot directly, or mention it in a channel:
|
||||
DM the Slack bot directly. It should return a pairing code. Approve it from a
|
||||
trusted local surface:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
Then DM the bot again, or mention it in a channel:
|
||||
|
||||
```text
|
||||
@nanobot Hello from Slack
|
||||
@@ -75,6 +87,7 @@ DM the Slack bot directly, or mention it in a channel:
|
||||
|
||||
- Keep `groupPolicy` as `mention` unless the bot is intentionally listening to
|
||||
every channel message.
|
||||
- Keep `dm.policy` as `"allowlist"` when you want pairing-based approval.
|
||||
- Use `groupAllowFrom` with allowlist mode for approved channels.
|
||||
- Reinstall the Slack app after changing scopes.
|
||||
- Keep bot and app tokens out of committed config files.
|
||||
@@ -84,6 +97,8 @@ DM the Slack bot directly, or mention it in a channel:
|
||||
- If Socket Mode fails, confirm the app-level token starts with `xapp-`.
|
||||
- If the bot cannot send files, add `files:write`, reinstall the app, and
|
||||
restart nanobot.
|
||||
- If a DM responds normally without pairing, check that `dm.policy` is
|
||||
`"allowlist"`.
|
||||
- If channel messages are ignored, check event subscriptions and group policy.
|
||||
|
||||
## Next: memory, automations, MCP tools
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Build a Telegram AI Agent with nanobot
|
||||
|
||||
This guide connects nanobot to Telegram so an allowed Telegram user can message
|
||||
a self-hosted AI agent backed by your normal nanobot config, tools, memory, and
|
||||
This guide connects nanobot to Telegram so a paired Telegram user can message a
|
||||
self-hosted AI agent backed by your normal nanobot config, tools, memory, and
|
||||
workspace.
|
||||
|
||||
## What this guide builds
|
||||
@@ -9,7 +9,7 @@ workspace.
|
||||
- a Telegram bot created through BotFather
|
||||
- the `telegram` channel enabled in nanobot
|
||||
- a running nanobot gateway
|
||||
- one test message from an allowed Telegram account
|
||||
- one pairing-approved Telegram account
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -21,7 +21,6 @@ nanobot agent -m "Hello!"
|
||||
|
||||
- A Telegram account.
|
||||
- A bot token from `@BotFather`.
|
||||
- Your Telegram user ID for `allowFrom`.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
@@ -45,13 +44,15 @@ Merge this snippet into `~/.nanobot/config.json`:
|
||||
"channels": {
|
||||
"telegram": {
|
||||
"enabled": true,
|
||||
"token": "YOUR_BOT_TOKEN",
|
||||
"allowFrom": ["YOUR_USER_ID"]
|
||||
"token": "YOUR_BOT_TOKEN"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Omitting `allowFrom` enables pairing-only mode. The first DM from a new user
|
||||
gets a pairing code instead of agent access.
|
||||
|
||||
Telegram uses long polling by default. Webhook mode is available for public
|
||||
HTTPS deployments; start with long polling for the first test.
|
||||
|
||||
@@ -66,19 +67,27 @@ Leave the gateway running while you test messages.
|
||||
|
||||
## Test a message
|
||||
|
||||
Open Telegram, message the bot from the user in `allowFrom`, and send:
|
||||
Open Telegram, DM the bot, and send:
|
||||
|
||||
```text
|
||||
Hello from Telegram
|
||||
```
|
||||
|
||||
The reply should use the same model and workspace as your local CLI check.
|
||||
The bot should reply with a pairing code. Approve it from an already trusted
|
||||
surface, such as the local CLI:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
Send the message again after approval. The reply should use the same model and
|
||||
workspace as your local CLI check.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Keep `allowFrom` to your own user ID until the bot is stable.
|
||||
- Do not use `allowFrom: ["*"]` unless the bot is isolated or intentionally
|
||||
public.
|
||||
- Prefer pairing-only mode for first setup. Add `allowFrom` only when you want a
|
||||
static allowlist instead of code approval.
|
||||
- Do not use `allowFrom: ["*"]` unless the bot is isolated or intentionally public.
|
||||
- Rotate the BotFather token if it is pasted into logs or shared files.
|
||||
- Review tool access before adding group chats or more users.
|
||||
|
||||
@@ -87,7 +96,9 @@ The reply should use the same model and workspace as your local CLI check.
|
||||
- If the channel is not listed, run `nanobot plugins enable telegram` again in
|
||||
the same Python environment.
|
||||
- If messages do not arrive, run `nanobot gateway --verbose` and check the bot
|
||||
token and allowed user ID.
|
||||
token.
|
||||
- If a first DM returns a pairing code, that is expected. Approve the code before
|
||||
testing normal agent replies.
|
||||
- If Telegram Web shows unsupported rich messages, keep `richMessages` disabled.
|
||||
|
||||
## Next: memory, automations, MCP tools
|
||||
|
||||
@@ -7,7 +7,7 @@ uses HTTP long polling with QR-code login through the supported upstream API.
|
||||
|
||||
- the `weixin` channel enabled in nanobot
|
||||
- a QR-code login session
|
||||
- one allowed WeChat sender
|
||||
- one pairing-approved WeChat sender
|
||||
- a running gateway for message delivery
|
||||
|
||||
## Prerequisites
|
||||
@@ -19,7 +19,6 @@ nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
- A WeChat account that can complete QR-code login.
|
||||
- The sender ID from logs for `allowFrom`, or a temporary private test setup.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
@@ -42,13 +41,15 @@ Merge this snippet into `~/.nanobot/config.json`:
|
||||
{
|
||||
"channels": {
|
||||
"weixin": {
|
||||
"enabled": true,
|
||||
"allowFrom": ["YOUR_WECHAT_USER_ID"]
|
||||
"enabled": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Omitting `allowFrom` enables pairing-only mode. The first private WeChat message
|
||||
from a new sender gets a pairing code instead of agent access.
|
||||
|
||||
Log in:
|
||||
|
||||
```bash
|
||||
@@ -66,12 +67,20 @@ nanobot gateway
|
||||
|
||||
## Test a message
|
||||
|
||||
Send a private WeChat message from the allowed account and watch gateway logs for
|
||||
the sender ID and reply.
|
||||
Send a private WeChat message to the bot. It should reply with a pairing code.
|
||||
Approve it from a trusted local surface:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
Send the message again after approval and watch gateway logs for the sender ID
|
||||
and reply.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Keep `allowFrom` narrow after you identify the sender ID.
|
||||
- Prefer pairing-only mode for first setup. Add `allowFrom` only when you want a
|
||||
static allowlist.
|
||||
- Treat saved login state as sensitive account access.
|
||||
- Avoid connecting personal accounts to untrusted workspaces or broad tool
|
||||
permissions.
|
||||
@@ -79,8 +88,10 @@ the sender ID and reply.
|
||||
## Troubleshooting
|
||||
|
||||
- If login fails, rerun `nanobot channels login weixin --force`.
|
||||
- If messages arrive but are ignored, update `allowFrom` with the sender ID
|
||||
shown in logs.
|
||||
- If a first private message returns a pairing code, that is expected. Approve
|
||||
the code before testing normal agent replies.
|
||||
- If messages are denied without a pairing code, check gateway logs for whether
|
||||
WeChat provided the context token required for nanobot to reply.
|
||||
- If polling disconnects, restart the gateway and check network reachability to
|
||||
the upstream service.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user