botholomew 0.12.5 → 0.14.0

package/README.md

@@ -13,12 +13,14 @@ that works its way through a task queue — reading email, summarizing
 documents, researching topics, organizing notes, and maintaining context
 over time — while you sleep, work, or chat with it.
 
-Unlike coding agents, Botholomew has **no shell and no direct access to
-your filesystem**. It can't edit files on disk — instead, it ingests local
-files, folders, and URLs into a DuckDB-backed context store that it can
-read, search, and summarize. External capabilities (email, Slack, the web,
-and hundreds of other services) are granted deliberately, per project,
-through MCP servers wired up via [MCPX](https://github.com/evantahler/mcpx).
+Botholomew has **no shell and no access to your real filesystem**. The
+agent's world is a sandboxed `context/` tree inside the project: it can
+read, write, edit, and grep files there, but cannot escape upward,
+follow symlinks, or touch anything outside. Local files and URLs are
+brought in through `botholomew context add`. External capabilities
+(email, Slack, the web, and hundreds of other services) are granted
+deliberately, per project, through MCP servers wired up via
+[MCPX](https://github.com/evantahler/mcpx).
 
 ---
 
@@ -27,13 +29,15 @@ through MCP servers wired up via [MCPX](https://github.com/evantahler/mcpx).
 - **Autonomous.** Background **workers** claim tasks, work them with Claude,
   and log every interaction. You can spawn one-shot workers on demand, a
   long-running `--persist` worker, or point cron at `botholomew worker run`.
-- **Portable.** Each project is a `.botholomew/` directory — markdown +
-  DuckDB. Copy it, share it, check it in (or `.gitignore` it).
-- **Your data, your disk.** Project state — tasks, threads, ingested
-  context, embeddings — lives in `.botholomew/`, indexed in DuckDB with
-  BM25 keyword search and `array_cosine_distance` vector search. Model
-  calls go direct to Anthropic and OpenAI; any further reach is scoped to
-  the MCP servers you add.
+- **Portable.** A project is just a directory of files — markdown for
+  prompts, tasks, schedules, and context; CSVs for conversation history.
+  Copy it, share it, `git diff` it, check it in (or `.gitignore` it).
+- **Your data, your disk.** Tasks, schedules, threads, and the agent's
+  context tree are all real files you can `vim`, `grep`, and `git`.
+  DuckDB is demoted to a single search-index sidecar (`index.duckdb`)
+  that's fully derivable from disk and safe to delete. Model calls go
+  direct to Anthropic; any further reach is scoped to the MCP servers
+  you add.
 - **Extensible.** External tools come from MCP servers via
   [MCPX](https://github.com/evantahler/mcpx) — run them locally (Gmail,
   Slack, GitHub) or connect through an MCP gateway like
@@ -42,11 +46,12 @@ through MCP servers wired up via [MCPX](https://github.com/evantahler/mcpx).
   Reusable workflows are defined as markdown "skills" (slash commands)
   that the chat agent can also create, edit, and search at runtime.
 - **Safe by default.** The agent has no shell and no direct filesystem
-  access. Out of the box, everything it can touch lives in `.botholomew/`;
-  every external capability is a MCP server you explicitly add.
-- **Concurrent.** Many workers can run at once. Each registers itself in
-  the DB and heartbeats; crashed workers get reaped and their tasks go
-  back into the queue automatically.
+  access. Every path-taking tool is sandboxed to the project's `context/`
+  tree (NFC normalization + lstat-walk to reject symlinks at any level);
+  every external capability is an MCP server you explicitly add.
+- **Concurrent.** Many workers can run at once. Each writes a pidfile
+  and heartbeats; tasks and schedules are claimed via `O_EXCL` lockfiles
+  and crashed workers get reaped automatically.
 - **Self-modifying.** The agent maintains its own `beliefs.md` and
   `goals.md` — it learns, updates its priors, and revises its goals as it
   works. It can also author its own slash-command skills mid-conversation,
@@ -88,7 +93,7 @@ bun run dev -- --help
 # 1. Initialize a project in the current directory
 botholomew init
 
-# 2. Add your Anthropic key to .botholomew/config.json, or export it
+# 2. Add your Anthropic key to config/config.json, or export it
 export ANTHROPIC_API_KEY=sk-ant-...
 # Embeddings run locally — no API key required.
 
@@ -110,25 +115,40 @@ want Botholomew to advance on its own.
 
 ## What a project looks like
 
+A project is the directory you ran `botholomew init` in. Every entity
+the agent or worker touches is a real file you can `vim`, `grep`, and
+`git diff`:
+
 ```
 my-project/
-  .botholomew/
-    soul.md               # always-loaded identity (not agent-editable)
-    beliefs.md            # always-loaded, agent-editable priors
-    goals.md              # always-loaded, agent-editable goals
-    capabilities.md       # always-loaded, agent-editable tool inventory
-    config.json           # models, tick interval, API keys
-    data.duckdb           # tasks, schedules, context, embeddings, logs
-    mcpx/servers.json     # external MCP servers (Gmail, Slack, …)
-    skills/               # slash commands (built-ins + user-defined)
-      summarize.md
-      standup.md
-      capabilities.md
-    logs/                 # per-worker log files (one file per spawned worker)
-      <worker-id>.log
+  config/config.json                # models, tick interval, API keys
+  prompts/                          # always-loaded markdown
+    soul.md                         #   identity (not agent-editable)
+    beliefs.md                      #   agent-editable priors
+    goals.md                        #   agent-editable goals
+    capabilities.md                 #   agent-editable tool inventory
+  skills/                           # slash commands (built-ins + user-defined)
+    summarize.md
+    standup.md
+    capabilities.md
+  mcpx/servers.json                 # external MCP servers (Gmail, Slack, …)
+  models/                           # local embedding model cache
+  context/                          # agent-writable knowledge tree
+  tasks/                            # one markdown file per task
+    <id>.md                         #   status & metadata in frontmatter
+    .locks/<id>.lock                #   O_EXCL claim file (held by a worker)
+  schedules/                        # one markdown file per schedule
+    <id>.md
+    .locks/<id>.lock
+  threads/<YYYY-MM-DD>/<id>.csv     # full conversation history
+  workers/<id>.json                 # worker pidfile + heartbeat
+  logs/<YYYY-MM-DD>/<id>.log        # per-worker logs
+  index.duckdb                      # search index sidecar (rebuildable; safe to delete)
 ```
 
-Everything the agent can touch is here. No surprises.
+`index.duckdb` is the only opaque file; everything else is plain text.
+Delete the index any time and `botholomew context reindex` rebuilds it
+from `context/`.
 
 ---
 
@@ -138,19 +158,19 @@ Everything the agent can touch is here. No surprises.
 
 | Command | Purpose |
 |---|---|
-| `botholomew init` | Create `.botholomew/` with templates and a fresh database |
+| `botholomew init` | Initialize the current directory as a project (refuses on iCloud/Dropbox/NFS without `--force`) |
 | `botholomew worker run\|start` | Run a worker (foreground or background); `--persist` for long-running, `--task-id <id>` to target one task |
 | `botholomew worker list\|status\|stop\|kill\|reap` | Inspect and manage running workers |
 | `botholomew chat` | Interactive Ink/React TUI |
-| `botholomew task list\|add\|view\|update\|reset\|delete` | Manage the task queue |
-| `botholomew schedule list\|add\|view\|enable\|disable\|trigger\|delete` | Recurring work |
-| `botholomew context add\|list\|search\|chunks\|refresh\|reembed\|delete` | Ingest & browse knowledge (files, folders, URLs); `reembed` rebuilds every vector after upgrading the embedding model; also exposes the agent's `read`/`write`/`tree`/`edit`/… tools as subcommands |
-| `botholomew capabilities` | Rescan built-in + MCPX tools and rewrite `.botholomew/capabilities.md` |
+| `botholomew task list\|add\|view\|update\|reset\|delete` | Manage the task queue (markdown files in `tasks/`) |
+| `botholomew schedule list\|add\|view\|enable\|disable\|trigger\|delete` | Recurring work (markdown files in `schedules/`) |
+| `botholomew context add\|import\|tree\|stats\|reindex\|search\|read\|write\|edit\|move\|delete\|…` | Bring files/URLs into `context/`; rebuild the search index; expose the agent's file/dir tools as CLI subcommands |
+| `botholomew capabilities` | Rescan built-in + MCPX tools and rewrite `prompts/capabilities.md` |
 | `botholomew mcpx servers\|list\|add\|remove\|info\|search\|exec\|ping\|auth\|deauth\|import-global\|…` | Configure external MCP servers (passthrough to `mcpx`) |
 | `botholomew skill list\|show\|create\|validate` | Manage slash-command skills |
-| `botholomew thread list\|view` | Browse the agent's interaction history |
-| `botholomew nuke context\|tasks\|schedules\|threads\|all` | Bulk-erase sections of the database |
-| `botholomew db doctor [--repair]` | Probe each table for primary-key index corruption; rebuild via EXPORT/IMPORT |
+| `botholomew thread list\|view` | Browse the agent's conversation history (CSVs in `threads/`) |
+| `botholomew nuke context\|tasks\|schedules\|threads\|all` | Bulk-erase project state |
+| `botholomew db doctor [--repair]` | Probe the search-index DB; rebuild via EXPORT/IMPORT |
 | `botholomew upgrade` | Self-update |
 
 All `list` subcommands support `-l, --limit <n>` and `-o, --offset <n>` for pagination.
@@ -166,25 +186,25 @@ All `list` subcommands support `-l, --limit <n>` and `-o, --offset <n>` for pagi
  │              │         │              │         │    (optional)│
  └──────┬───────┘         └──────┬───────┘         └──────┬───────┘
         │                        │                        │
-        │ enqueue tasks          │ register + heartbeat   │ fire
-        │ browse history         │ claim tasks            │ `worker run`
+        │ enqueue tasks          │ pidfile + heartbeat    │ fire
+        │ browse history         │ claim via O_EXCL lock  │ `worker run`
         │ spawn_worker tool      │ run LLM tool loops     │ on a
-        │ invoke skills          │ reap dead peers        │ schedule
-        │                        │ log to threads         │
+        │ invoke skills          │ reap orphan locks      │ schedule
+        │                        │ log threads → CSV      │
         └────────────┬───────────┴────────────┬───────────┘
                      │                        │
-               ┌─────▼────────────────────────▼─────┐
-               │        DuckDB                       │
-               │  ┌───────────┐ ┌──────────────┐    │
-               │  │  tasks    │ │ context_items│    │
-               │  │ schedules │ │  embeddings  │    │
-               │  │  workers  │ │  (FTS+vector)│    │
-               │  │  threads  │ │              │    │
-               │  └───────────┘ └──────────────┘    │
-               └─────┬───────────────────────────────┘
-                     │
-                     ▼
-              MCPX ─► Gmail, Slack, GitHub, Firecrawl, …
+              ┌──────▼────────────────────────▼──────┐
+              │     <project-root>/                   │
+              │       tasks/<id>.md                   │
+              │       schedules/<id>.md               │
+              │       threads/<date>/<id>.csv         │
+              │       workers/<id>.json               │
+              │       context/  ─►  index.duckdb      │
+              │                     (search sidecar)  │
+              └──────────────────┬────────────────────┘
+                                 │
+                                 ▼
+                  MCPX ─► Gmail, Slack, GitHub, Firecrawl, …
 ```
 
 See [docs/architecture.md](docs/architecture.md) for a deeper tour.
@@ -205,17 +225,19 @@ Topics worth understanding in detail:
 - **[The TUI](docs/tui.md)** — the `botholomew chat` Ink/React terminal UI:
   eight tabs, slash-command autocomplete, message queue, tool-call
   visualization, and a live workers panel.
-- **[The virtual filesystem](docs/virtual-filesystem.md)** — why the agent's
-  "files" are actually DuckDB rows, and how `context_read`/`context_write` work.
+- **[Files & the sandbox](docs/files.md)** — the agent's `context/`
+  tree, the path sandbox (NFC + lstat-walk), and how
+  `context_read`/`context_write`/`context_edit` work.
 - **[Context & hybrid search](docs/context-and-search.md)** — LLM-driven
-  chunking, OpenAI embeddings, and DuckDB BM25 + linear-scan vector
+  chunking, local embeddings, and DuckDB BM25 + linear-scan vector
   search merged with reciprocal rank fusion.
-- **[Tasks & schedules](docs/tasks-and-schedules.md)** — the claim loop, DAG
-  validation, stale-task recovery, and natural-language recurring schedules.
+- **[Tasks & schedules](docs/tasks-and-schedules.md)** — markdown
+  frontmatter as the source of truth, lockfile-based claim, DAG
+  validation, and natural-language recurring schedules.
 - **[The Tool class](docs/tools.md)** — one Zod definition, three consumers
   (Anthropic tool-use, Commander CLI, tests).
-- **[Persistent context](docs/persistent-context.md)** — `soul.md`,
-  `beliefs.md`, `goals.md`, frontmatter flags, and agent self-modification.
+- **[Prompts](docs/prompts.md)** — `soul.md`, `beliefs.md`, `goals.md`,
+  frontmatter flags, and agent self-modification.
 - **[Skills (slash commands)](docs/skills.md)** — reusable prompt templates
   with positional arguments and tab completion; the chat agent can also
   create, edit, and search them at runtime.
@@ -231,9 +253,10 @@ Topics worth understanding in detail:
 ## Tech stack
 
 - **[Bun](https://bun.sh)** + TypeScript
-- **[DuckDB](https://duckdb.org)** via `@duckdb/node-api` —
-  `array_cosine_distance()` (core DuckDB) for vector search, plus the
-  built-in FTS extension for BM25 keyword search
+- **[DuckDB](https://duckdb.org)** via `@duckdb/node-api` — drives the
+  search-index sidecar only. `array_cosine_distance()` (core DuckDB) for
+  vector search, plus the built-in FTS extension for BM25 keyword
+  search; the index is rebuildable from `context/` at any time
 - **[Anthropic SDK](https://docs.anthropic.com/en/api/client-sdks)** for
   Claude — the reasoning model
 - **[`@huggingface/transformers`](https://huggingface.co/docs/transformers.js)**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "botholomew",
-  "version": "0.12.5",
+  "version": "0.14.0",
   "description": "An autonomous AI agent for knowledge work — works your task queue while you sleep.",
   "type": "module",
   "bin": {
@@ -16,7 +16,7 @@
     "url": "https://github.com/evantahler/botholomew.git"
   },
   "scripts": {
-    "dev": "bun run src/cli.ts",
+    "dev": "bun run src/cli.ts -d .botholomew",
     "dev:demo": "bun run src/cli.ts chat -p 'learn everything you can about me from the connected MCP services and then save what you'\\''ve learned about me to context'",
     "test": "bun test",
     "lint": "tsc --noEmit && biome check .",

package/src/chat/agent.ts

@@ -8,10 +8,8 @@ import type {
 } from "@anthropic-ai/sdk/resources/messages";
 import type { McpxClient } from "@evantahler/mcpx";
 import type { BotholomewConfig } from "../config/schemas.ts";
-import { embedSingle } from "../context/embedder.ts";
 import { withDb } from "../db/connection.ts";
-import { hybridSearch } from "../db/embeddings.ts";
-import { logInteraction } from "../db/threads.ts";
+import { logInteraction } from "../threads/store.ts";
 import { registerAllTools } from "../tools/registry.ts";
 import {
   getAllTools,
@@ -19,7 +17,6 @@ import {
   type ToolContext,
   toAnthropicTool,
 } from "../tools/tool.ts";
-import { logger } from "../utils/logger.ts";
 import { fitToContextWindow, getMaxInputTokens } from "../worker/context.ts";
 import { maybeStoreResult } from "../worker/large-results.ts";
 import { createLlmClient } from "../worker/llm-client.ts";
@@ -38,17 +35,15 @@ const CHAT_TOOL_NAMES = new Set([
   "create_task",
   "list_tasks",
   "view_task",
-  "context_search",
   "context_info",
-  "context_refresh",
   "context_tree",
-  "context_list_drives",
   "context_read",
   "context_write",
   "context_edit",
   "search",
   "list_threads",
   "view_thread",
+  "search_threads",
   "create_schedule",
   "list_schedules",
   "update_beliefs",
@@ -67,6 +62,7 @@ const CHAT_TOOL_NAMES = new Set([
   "skill_edit",
   "skill_search",
   "skill_delete",
+  "sleep",
 ]);
 
 export function getChatTools() {
@@ -91,39 +87,14 @@ export async function buildChatSystemPrompt(
 
   prompt += await loadPersistentContext(projectDir, taskKeywords);
 
-  const dbPath = options?.dbPath;
-  const config = options?.config;
-  if (dbPath && config && keywordSource) {
-    try {
-      const queryVec = await embedSingle(keywordSource, config);
-      const results = await withDb(dbPath, (conn) =>
-        hybridSearch(conn, keywordSource, queryVec, 5),
-      );
-
-      if (results.length > 0) {
-        prompt += "## Relevant Context\n";
-        for (const r of results) {
-          const ref =
-            r.drive && r.path ? `${r.drive}:${r.path}` : r.context_item_id;
-          prompt += `### ${r.title} (${ref})\n`;
-          if (r.chunk_content) {
-            prompt += `${r.chunk_content.slice(0, 1000)}\n`;
-          }
-          prompt += "\n";
-        }
-      }
-    } catch (err) {
-      logger.debug(`Failed to load contextual embeddings: ${err}`);
-    }
-  }
-
   prompt += `## Instructions
 You are Botholomew, an AI agent personified by a wise owl. This is your interactive chat interface. Help the user manage tasks, review results from background worker activity, search context, and answer questions.
 You do NOT execute long-running work directly — enqueue tasks for a background worker instead using create_task, and spawn a worker via spawn_worker when the user wants the task run now.
-Use the available tools to look up tasks, threads, schedules, and context when the user asks about them. Context items live under a drive (disk / url / agent / google-docs / github / …); use \`context_list_drives\` to discover which drives have content, then \`context_tree\`, \`context_info\`, \`context_search\`, or \`context_refresh\` as needed.
+Use the available tools to look up tasks, threads, schedules, and context when the user asks about them. Files the agent can read and write live under \`context/\` as project-relative paths (e.g. \`notes/foo.md\`). Use \`context_tree\` to see what's there, \`search\` (hybrid regexp + semantic) to find content, then \`context_read\` / \`context_info\` to drill in.
+Past conversations live in CSV files under \`threads/\`; use \`list_threads\`, \`search_threads\`, and \`view_thread\` to find and page through them.
 When multiple tool calls are independent of each other (i.e., one does not depend on the result of another), call them all in a single response. They will be executed in parallel, which is faster than calling them one at a time.
 You can update the agent's beliefs and goals files when the user asks you to.
-You can author and refine slash-command skills (reusable prompt templates stored in \`.botholomew/skills/\`) via \`skill_list\`, \`skill_search\`, \`skill_read\`, \`skill_write\`, \`skill_edit\`, and \`skill_delete\`. New or edited skills are usable as \`/<name>\` on the user's next message.
+You can author and refine slash-command skills (reusable prompt templates stored in \`skills/\`) via \`skill_list\`, \`skill_search\`, \`skill_read\`, \`skill_write\`, \`skill_edit\`, and \`skill_delete\`. New or edited skills are usable as \`/<name>\` on the user's next message.
 Format your responses using Markdown. Use headings, bold, italic, lists, and code blocks to make your responses clear and well-structured.
 `;
 
@@ -133,19 +104,19 @@ Format your responses using Markdown. Use headings, bold, italic, lists, and cod
 
 ### Local context first
 
-**Before any MCP read, search local context.** Drive, Gmail, GitHub, URLs, and prior agent runs are usually already ingested — refetching is slower, costs tokens, and risks rate limits.
+**Before any MCP read, search local context.** Files in \`context/\` (Gmail dumps, GitHub fetches, URL ingests, prior agent outputs) are usually already there — refetching is slower, costs tokens, and risks rate limits.
 
 Workflow for any "look up / find / read" intent:
 
-1. \`search\` (hybrid regexp + semantic) or \`context_search\` (keyword), then \`context_read\` / \`context_tree\` to drill in.
-2. If freshness matters, call \`context_info\` and check \`indexed_at\`. To re-pull a single stale item, use \`context_refresh\` rather than going to MCP for the whole document.
+1. \`search\` (hybrid regexp + semantic) over \`context/\`, then \`context_read\` / \`context_tree\` to drill in.
+2. If freshness matters, call \`context_info\` and check the file's mtime. To re-pull stale content, write fresh into \`context/\` (\`pipe_to_context\` from an \`mcp_exec\` call is the typical path) rather than going to MCP for the whole document on every question.
 3. Only call \`mcp_exec\` for reads when the data is genuinely missing locally **or** must be real-time (e.g., "what's on my calendar right now").
 
 Writes always go through MCP — sending an email, creating an issue, posting to Slack. Don't search context first for those.
 
 Examples:
 - "What does doc X say?" → \`search\` first.
-- "Any new emails from Y?" → check the \`gmail\` drive first; only hit Gmail MCP if the freshest indexed item is too old for the question.
+- "Any new emails from Y?" → \`search\` for the sender under \`context/gmail/\` (or wherever you've been ingesting mail) before hitting Gmail MCP.
 - "Send an email to Y" → MCP write directly; no context lookup.
 
 ### Calling MCP tools
@@ -250,13 +221,11 @@ export async function runChatTurn(input: {
     // the whole tool loop to finish.
     const injections = callbacks.takeInjections?.() ?? [];
     for (const text of injections) {
-      await withDb(dbPath, (conn) =>
-        logInteraction(conn, threadId, {
-          role: "user",
-          kind: "message",
-          content: text,
-        }),
-      );
+      await logInteraction(projectDir, threadId, {
+        role: "user",
+        kind: "message",
+        content: text,
+      });
       messages.push({ role: "user", content: text });
     }
 
@@ -327,15 +296,13 @@ export async function runChatTurn(input: {
       // `assistantText` is the right partial value). Deliberately drop any
       // partial tool_use blocks — they would be unmatched on the next turn.
       if (assistantText) {
-        await withDb(dbPath, (conn) =>
-          logInteraction(conn, threadId, {
-            role: "assistant",
-            kind: "message",
-            content: assistantText,
-            durationMs: Date.now() - startTime,
-            tokenCount: 0,
-          }),
-        );
+        await logInteraction(projectDir, threadId, {
+          role: "assistant",
+          kind: "message",
+          content: assistantText,
+          durationMs: Date.now() - startTime,
+          tokenCount: 0,
+        });
         messages.push({ role: "assistant", content: assistantText });
       }
       return;
@@ -348,15 +315,13 @@ export async function runChatTurn(input: {
 
     // Log assistant text
     if (assistantText) {
-      await withDb(dbPath, (conn) =>
-        logInteraction(conn, threadId, {
-          role: "assistant",
-          kind: "message",
-          content: assistantText,
-          durationMs,
-          tokenCount,
-        }),
-      );
+      await logInteraction(projectDir, threadId, {
+        role: "assistant",
+        kind: "message",
+        content: assistantText,
+        durationMs,
+        tokenCount,
+      });
     }
 
     // Check for tool calls
@@ -380,15 +345,13 @@ export async function runChatTurn(input: {
         callbacks.onToolStart(toolUse.id, toolUse.name, toolInput);
       }
 
-      await withDb(dbPath, (conn) =>
-        logInteraction(conn, threadId, {
-          role: "assistant",
-          kind: "tool_use",
-          content: `Calling ${toolUse.name}`,
-          toolName: toolUse.name,
-          toolInput,
-        }),
-      );
+      await logInteraction(projectDir, threadId, {
+        role: "assistant",
+        kind: "tool_use",
+        content: `Calling ${toolUse.name}`,
+        toolName: toolUse.name,
+        toolInput,
+      });
     }
 
     // Execute all tools in parallel. Each tool call opens its own short-lived
@@ -402,6 +365,7 @@ export async function runChatTurn(input: {
           projectDir,
           config,
           mcpxClient,
+          shouldAbort: session ? () => session.aborted : undefined,
         });
         const durationMs = Date.now() - start;
         const stored = maybeStoreResult(toolUse.name, result.output);
@@ -422,15 +386,13 @@ export async function runChatTurn(input: {
     // Log results and collect tool_result messages
     const toolResults: ToolResultBlockParam[] = [];
     for (const { toolUse, result, durationMs, stored } of execResults) {
-      await withDb(dbPath, (conn) =>
-        logInteraction(conn, threadId, {
-          role: "tool",
-          kind: "tool_result",
-          content: result.output,
-          toolName: toolUse.name,
-          durationMs,
-        }),
-      );
+      await logInteraction(projectDir, threadId, {
+        role: "tool",
+        kind: "tool_result",
+        content: result.output,
+        toolName: toolUse.name,
+        durationMs,
+      });
 
       toolResults.push({
         type: "tool_result",
@@ -451,6 +413,7 @@ interface ChatToolCallCtx {
   projectDir: string;
   config: Required<BotholomewConfig>;
   mcpxClient: McpxClient | null;
+  shouldAbort?: () => boolean;
 }
 
 async function executeChatToolCall(
@@ -474,10 +437,20 @@ async function executeChatToolCall(
   }
 
   try {
-    const result = await withDb(baseCtx.dbPath, (conn) => {
-      const ctx: ToolContext = { ...baseCtx, conn };
-      return tool.execute(parsed.data, ctx);
-    });
+    // `sleep` deliberately yields for up to an hour; opening a DuckDB
+    // connection for that whole window would hold the instance-level file
+    // lock and block any worker that also wants the DB. Run it without a
+    // connection — the tool doesn't touch the DB.
+    const runWithoutDb = tool.name === "sleep";
+    const result = runWithoutDb
+      ? await tool.execute(parsed.data, {
+          ...baseCtx,
+          conn: undefined as unknown as ToolContext["conn"],
+        })
+      : await withDb(baseCtx.dbPath, (conn) => {
+          const ctx: ToolContext = { ...baseCtx, conn };
+          return tool.execute(parsed.data, ctx);
+        });
     const isError =
       typeof result === "object" && result !== null && "is_error" in result
         ? (result as { is_error: boolean }).is_error