Question 1

Why does my SKILL.md show an empty name and description in the skills API (UTF-8 BOM issue)?

Accepted Answer

The file was saved as "UTF-8 with BOM" — common with Windows Notepad or PowerShell 5.1 `Set-Content -Encoding UTF8`. The invisible BOM character (U+FEFF) before the opening `---` fence made the frontmatter parser fail to detect the YAML block, so the entire file was treated as body and name/description appeared empty.

Fix: This is resolved on the `develop` branch. The shared frontmatter helper (`src/octop/infra/utils/frontmatter.py::parse_frontmatter`) now strips a single leading U+FEFF before scanning for the `---` fence, and the skills router (`src/octop/api/routers/skills.py`) was consolidated to use this shared parser instead of its local `_parse_frontmatter`.

Workaround on older versions: re-save the SKILL.md as UTF-8 *without* BOM (e.g., in VS Code select "UTF-8" instead of "UTF-8 with BOM" in the status bar encoding menu), or remove the BOM programmatically before parsing with `text.lstrip('\ufeff')`.

Question 2

How to fix Octop LDAP error 'enabling LDAP over ldap:// requires StartTLS; otherwise use an ldaps:// URL'?

Accepted Answer

This is an intentional security restriction in Octop (`infra/auth/ldap/config.py`), not a bug: plaintext `ldap://` is blocked so passwords are not sent in clear text, and there is no toggle in security settings to disable it. Fixes: 1) Change the server URL to `ldaps://` (e.g., `ldaps://192.168.1.1:636`) with LDAPS enabled on your Windows AD domain controller; or 2) Enable StartTLS on the AD server and turn on the StartTLS option in Octop's LDAP config while keeping `ldap://192.168.1.1:389`. If you need an explicit 'allow insecure plaintext' escape hatch, submit a feature request.

Question 3

How to fix octop memory overflow (OOM) when agent runs filesystem search without ripgrep?

Accepted Answer

This is a known bug in octop 1.0.1 (deepagents 0.7.9): when ripgrep (`rg`) is not on PATH, an unscoped grep search falls back to a pure-Python search that walks from `/` and reads pseudo-files like `/proc/<pid>/pagemap` with unbounded `readline()`, exhausting host memory. Fixes and mitigations:

1. **Upgrade to octop v1.0.2+** — fixed by PR #2116: the official image now ships ripgrep (killable subprocess path), and `OctopServer.start()` patches deepagents' `_python_search` to skip `/proc`, `/sys`, `/dev` and cap per-line/per-file read size.

2. **Install ripgrep in the container** — add a static `rg` binary to PATH so the Python fallback is never used.

3. **Set a container memory limit** — e.g. `docker run --memory=4g ...` so the kernel OOM-kills only the container, not the whole host.

4. **Restrict `backend.root_dir`** — avoid the default `root_dir='/'` which gives the agent shell access to the entire host filesystem.

Question 4

How to fix "AdminShutdown: terminating connection due to administrator command" error with psycopg ConnectionPool in langgraph Postgres checkpointer?

Accepted Answer

The error occurs because psycopg_pool's `ConnectionPool` defaults to `check=None` (no liveness probe), so when `max_lifetime` (default 3600s) recycling coincides with concurrent `getconn()` calls, a terminated connection is handed to the caller and `execute()` fails fatally. Fix: build the pool with an explicit liveness check and explicit max_lifetime.

```python
from psycopg_pool import ConnectionPool

def _check_conn(conn):
    conn.execute("SELECT 1")

pool = ConnectionPool(
    conninfo=dsn,
    min_size=1,
    max_size=4,
    check=_check_conn,        # probe and discard dead connections before handing out
    max_lifetime=3600,        # set explicitly; consider aligning below PG/server-side timeout
    kwargs={"autocommit": True, "prepare_threshold": 0, "row_factory": dict_row},
    open=True,
)
```

The `check` callback runs `SELECT 1` before a connection is given out; dead connections are detected, discarded, and rebuilt transparently. As additional hardening, wrap the `PostgresSaver`/`get_tuple` execute path with a retry on `psycopg.errors.AdminShutdown` (or `OperationalError`) so a single dead connection is not fatal to the job. This affects psycopg 3.x / psycopg_pool 3.3.x with langgraph Postgres checkpointer setups under concurrent cron-like workloads.

Question 5

How to fix Octop replies starting with {"matches":...} memory JSON that break WeChat sending (ret=-2 prepare failed)?

Accepted Answer

Root cause: when a cron prompt asks the agent to call memory_save, the model first tries editing MEMORY.md, gets blocked by FilesystemGuard, then falls back to the memory tool chain. The internal reconciliation JSON ({"matches":[{"atom_id",...}]} from octop_memory/operations/retention.py) enters the main dialogue context and the model parrots it at the start of the final reply (reproduced on glm-5.3-flash and glm-4.6, model-agnostic). The bloated content (up to ~220k chars) gets split into ~2000-char segments by the WeChat channel, triggering rate limiting 'ret=-2, errmsg=prepare failed' and message loss. Verified workaround (self-hosted): 1) Set "memory_recall_inject_enabled": false in the agent config to disable the automatic <memory-context> injection that also leaks atom_id and recall metadata to channels. 2) Rewrite cron/automation prompts to avoid memory_* tools; record history in a plain workspace file instead (e.g., read/write dinner-log.md). After both changes, the same cron task produces clean output (standard format under 400 chars, sent in a single segment). Long-term fix requires the reconcile JSON to stay inside the memory service, recall injection to render as plain summaries without atom_id, and the channel layer to filter/truncate injected blocks and abnormally long content.

Octop

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects