Q: Why does nanobot CLI crash on macOS with UnicodeDecodeError when the command ends with Chinese/Japanese/Korean text?

Cause: nanobot <=0.3.5 sets `SPT_NOENV=1` unconditionally before importing setproctitle. On macOS this confines the process-title buffer to the argv area, where setproctitle <=1.3.8 drops the final byte (upstream bug dvarrazzo/py-setproctitle#167). If the command line ends with a multibyte UTF-8 character (CJK/emoji), the truncated byte sequence causes setproctitle's macOS-only import-time `getproctitle()` to raise `UnicodeDecodeError: 'utf-8' codec can't decode bytes`, killing the CLI before any model call. Fix (in `nanobot/cli/process_identity.py`): only set SPT_NOENV on Linux, where it is actually meaningful: ```python import sys if sys.platform == "linux": os.environ.setdefault("SPT_NOENV", "1") ``` Optionally wrap the setproctitle import/call in try/except so cosmetic process naming can never crash the CLI. Workarounds until a patched release is installed: (1) append an ASCII character (e.g. a trailing space) after the CJK text so argv does not end with a multibyte character; (2) edit the installed `process_identity.py` in your uv tool environment with the patch above. Note: exporting SPT_NOENV yourself does not help, because setproctitle only checks the variable's presence, not its value. Linux is unaffected (byte loss is cosmetic there, no crash).

Q: How to fix nanobot webui memory leak (high RAM usage) on Windows 11?

The leak is in `nanobot/process_runtime.py::_windows_process_identity()`, which redefines a `ctypes.Structure` subclass and a fresh `ctypes.WinDLL("kernel32")` on every call. `ctypes._pointer_type_cache` permanently retains these type objects (~6.5 KB/call), and since the WebUI launcher polls `runtime.status()` every 0.5s and the gateway polls client state every 1s, memory grows ~2.6 MB/min (~3.7 GB/day) even when idle. Fix: upgrade to the nanobot release containing PR #6507. As a manual workaround, patch `process_runtime.py` so the `FileTime` structure, its `ctypes.POINTER` types, and the kernel32 `WinDLL` binding are created only once at module level (e.g., via `@lru_cache(maxsize=1)` on a `_windows_kernel32()` helper), instead of on every call.

Q: How to run multiple nanobot instances on Windows without Telegram 'Conflict' error?

On Windows, nanobot ignores the `NANOBOT_HOME` environment variable and always defaults to `C:\Users\ \.nanobot`, so two instances load the same `config.json` and the same Telegram Bot Token, causing a `telegram.error.Conflict` loop. **Workaround:** override `USERPROFILE` for the second process before launching: CMD: ``` set "USERPROFILE=C:\Path\To\Alternative\Home" nanobot gateway ``` **Permanent fix (upcoming):** PR #6128 adds an explicit `--home` CLI option placed before the subcommand: ``` nanobot --home onboard nanobot --home gateway ``` Each instance then uses its own config and workspace under that directory. Note: `NANOBOT_HOME` support was rejected in favor of `--home`; explicit config/workspace settings still take precedence.

Q: Why does DuckDuckGo web_search fail with "No results found" error on consecutive searches, and how to fix it?

The `DuckDuckGo search failed (No results found.)` error is ambiguous — it does NOT confirm zero matches. The `ddgs` library hides upstream refusals (e.g., Mojeek HTTP 403 blocks), parsing failures, and aggregation errors behind this generic exception. Firing multiple distinct queries with no pause triggers the failures; the same queries succeed when spaced out. **Workaround — pace your searches:** Add ~3 second pauses between web_search calls. Verified repro: 8 distinct queries with no pause → 0/8 results (all `DDGSException: No results found`); same 8 queries with 3s pause → 8/8 results. ```python from ddgs import DDGS d = DDGS(timeout=15) # no pause -> all queries fail with DDGSException: No results found # 3s pause between queries -> all return results ``` **Permanent fix (PR #6409):** The tool now reports ambiguous ddgs failures honestly as "no usable search result obtained, cause unknown" instead of presenting them as confirmed zero matches. It also distinguishes the tool's own waiting deadline from a timeout reported by ddgs, while preserving result formatting, network route, cancellation, and diagnostic privacy. **Out of scope:** Removing upstream rate limits/anti-automation blocks, and adding automatic retry/backoff/pacing config. Do not assume every `No results found` error is rate limiting. Upstream error preservation is tracked separately at https://github.com/deedy5/ddgs/issues/478.

Question 1

Why does nanobot CLI crash on macOS with UnicodeDecodeError when the command ends with Chinese/Japanese/Korean text?

Accepted Answer

Cause: nanobot <=0.3.5 sets `SPT_NOENV=1` unconditionally before importing setproctitle. On macOS this confines the process-title buffer to the argv area, where setproctitle <=1.3.8 drops the final byte (upstream bug dvarrazzo/py-setproctitle#167). If the command line ends with a multibyte UTF-8 character (CJK/emoji), the truncated byte sequence causes setproctitle's macOS-only import-time `getproctitle()` to raise `UnicodeDecodeError: 'utf-8' codec can't decode bytes`, killing the CLI before any model call.

Fix (in `nanobot/cli/process_identity.py`): only set SPT_NOENV on Linux, where it is actually meaningful:
```python
import sys
if sys.platform == "linux":
    os.environ.setdefault("SPT_NOENV", "1")
```
Optionally wrap the setproctitle import/call in try/except so cosmetic process naming can never crash the CLI.

Workarounds until a patched release is installed: (1) append an ASCII character (e.g. a trailing space) after the CJK text so argv does not end with a multibyte character; (2) edit the installed `process_identity.py` in your uv tool environment with the patch above. Note: exporting SPT_NOENV yourself does not help, because setproctitle only checks the variable's presence, not its value. Linux is unaffected (byte loss is cosmetic there, no crash).

Question 2

How to fix nanobot webui memory leak (high RAM usage) on Windows 11?

Accepted Answer

The leak is in `nanobot/process_runtime.py::_windows_process_identity()`, which redefines a `ctypes.Structure` subclass and a fresh `ctypes.WinDLL("kernel32")` on every call. `ctypes._pointer_type_cache` permanently retains these type objects (~6.5 KB/call), and since the WebUI launcher polls `runtime.status()` every 0.5s and the gateway polls client state every 1s, memory grows ~2.6 MB/min (~3.7 GB/day) even when idle. Fix: upgrade to the nanobot release containing PR #6507. As a manual workaround, patch `process_runtime.py` so the `FileTime` structure, its `ctypes.POINTER` types, and the kernel32 `WinDLL` binding are created only once at module level (e.g., via `@lru_cache(maxsize=1)` on a `_windows_kernel32()` helper), instead of on every call.

Question 3

How to run multiple nanobot instances on Windows without Telegram 'Conflict' error?

Accepted Answer

On Windows, nanobot ignores the `NANOBOT_HOME` environment variable and always defaults to `C:\Users\\.nanobot`, so two instances load the same `config.json` and the same Telegram Bot Token, causing a `telegram.error.Conflict` loop. **Workaround:** override `USERPROFILE` for the second process before launching: CMD: ``` set "USERPROFILE=C:\Path\To\Alternative\Home" nanobot gateway ``` **Permanent fix (upcoming):** PR #6128 adds an explicit `--home` CLI option placed before the subcommand: ``` nanobot --home onboard nanobot --home gateway ``` Each instance then uses its own config and workspace under that directory. Note: `NANOBOT_HOME` support was rejected in favor of `--home`; explicit config/workspace settings still take precedence.

Question 4

Why does DuckDuckGo web_search fail with "No results found" error on consecutive searches, and how to fix it?

Accepted Answer

The `DuckDuckGo search failed (No results found.)` error is ambiguous — it does NOT confirm zero matches. The `ddgs` library hides upstream refusals (e.g., Mojeek HTTP 403 blocks), parsing failures, and aggregation errors behind this generic exception. Firing multiple distinct queries with no pause triggers the failures; the same queries succeed when spaced out.

**Workaround — pace your searches:** Add ~3 second pauses between web_search calls. Verified repro: 8 distinct queries with no pause → 0/8 results (all `DDGSException: No results found`); same 8 queries with 3s pause → 8/8 results.

```python
from ddgs import DDGS
d = DDGS(timeout=15)
# no pause -> all queries fail with DDGSException: No results found
# 3s pause between queries -> all return results
```

**Permanent fix (PR #6409):** The tool now reports ambiguous ddgs failures honestly as "no usable search result obtained, cause unknown" instead of presenting them as confirmed zero matches. It also distinguishes the tool's own waiting deadline from a timeout reported by ddgs, while preserving result formatting, network route, cancellation, and diagnostic privacy.

**Out of scope:** Removing upstream rate limits/anti-automation blocks, and adding automatic retry/backoff/pacing config. Do not assume every `No results found` error is rate limiting. Upstream error preservation is tracked separately at https://github.com/deedy5/ddgs/issues/478.

Question 5

Why does nanobot-ai consume high CPU every second when idle, and how to fix it?

Accepted Answer

Cause: In nanobot-ai 0.3.0, `AgentLoop.run` calls `auto_compact.check_expired(...)` on every 1-second `bus.consume_inbound()` timeout (`nanobot/agent/loop.py`, ~line 1032). Each call runs `SessionManager.list_sessions()`, which opens and parses every `sessions/*.jsonl` file, then fully loads each expired session via `_has_compactable_idle_tail`. With thousands of session files, the entire directory is re-read ~once per second, evicting the session LRU cache on every pass and throttling CPU even with zero active turns (measured ~0.14s per tick at 2,000 files).

Workaround: subclass `AutoCompact` and override `check_expired` to throttle scans and cache results, e.g.:

```python
import time
from nanobot.agent.compact import AutoCompact

class ThrottledAutoCompact(AutoCompact):
    def __init__(self, *args, scan_interval: float = 60.0, **kwargs):
        super().__init__(*args, **kwargs)
        self._scan_interval = scan_interval
        self._last_scan = 0.0
        self._no_compact_cache = set()  # session ids verified to have nothing to compact

def check_expired(self, *args, **kwargs):
        now = time.monotonic()
        if now - self._last_scan < self._scan_interval:
            return None  # skip scan between intervals
        self._last_scan = now
        return super().check_expired(*args, **kwargs)
```

Then inject `ThrottledAutoCompact` in place of the default `AutoCompact` when constructing the agent loop, and skip sessions already recorded in `_no_compact_cache` until they receive new turns. This reduces idle scanning cost from once per second to once per minute. Long-term fix requires an upstream change: a bounded idle scan or an index/cached-metadata layer so cost no longer scales with total session file count.

nanobot

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects