alvin-bot 4.12.1 → 4.12.3

package/CHANGELOG.md

@@ -2,6 +2,151 @@
 
 All notable changes to Alvin Bot are documented here.
 
+## [4.12.3] — 2026-04-15
+
+### 🐛 Patch: Background sub-agent no longer blocks the main Telegram session
+
+**The bug Ali reported:** After launching an async sub-agent (`run_in_background: true`), sending any follow-up message to the bot silently stalled for 2+ minutes before being processed. v4.12.1/v4.12.2 attempted a prompt-hint mitigation but did NOT address the architectural root cause.
+
+**Root cause (re-diagnosed with live SDK event logs):** The Claude Agent SDK's CLI subprocess stays alive for the full duration of a background task so it can inject the `<task-notification>` inline into the NEXT assistant turn. While that subprocess idles, Alvin's query iterator is still being drained, `session.isProcessing` stays `true`, and every new user message gets pushed into the 3-slot queue — which doesn't auto-drain. From the user's perspective: send "A" → nothing happens for 2 minutes.
+
+**The fix (architectural workaround):** New session field `pendingBackgroundCount` tracks the number of background agents currently in-flight. When a new message arrives while `isProcessing=true` AND the counter is `>0`, the handler:
+
+1. **Aborts the blocked query** instead of queueing. The old SDK subprocess dies; the background task's own detached subprocess keeps writing to its `output_file`.
+2. **Starts a fresh SDK session** (`resume: null`) for the new message so it doesn't inherit the block. Recent conversation history is carried forward via the bridge preamble so Claude retains context.
+3. **Relies on the existing `async-agent-watcher` (v4.10.0)** to poll the background task's `output_file` and deliver the result as a separate Telegram message via `subagent-delivery.ts`. The watcher decrements the counter when it delivers, so subsequent messages go back to normal SDK-resume behavior.
+
+**Net effect:** Sending "A" during a 5-minute research task now gets processed in ~200ms instead of after 5 minutes. The background research still delivers its result via a separate message when ready.
+
+### Technical details
+
+**New module** `src/handlers/background-bypass.ts` — pure state-machine helpers:
+- `shouldBypassQueue(state)` — returns true when `isProcessing=true`, `pendingBackgroundCount>0`, and an unaborted `abortController` exists
+- `shouldBypassSdkResume(state)` — returns true when `pendingBackgroundCount>0`, signalling the next query should pass `sessionId=null`
+- `waitUntilProcessingFalse(session, timeoutMs, tickMs)` — poll-waits for the old handler's `finally` block to flip the flag before the new query starts
+
+**`src/services/session.ts`** — new field `pendingBackgroundCount: number` (default 0, reset on `/new`). Not persisted across restarts — the watcher re-hydrates its own state file and delivery still works, and starting a fresh counter after restart avoids stale drift.
+
+**`src/services/async-agent-watcher.ts`** — `PendingAsyncAgent` gets an optional `sessionKey` field. On every delivery path (completed/failed/timeout), a new `decrementPendingCount(sessionKey)` helper clamps the counter at 0 using `Math.max`. Missing/unknown session keys are a no-op (backwards compatible with pre-v4.12.3 persisted state files).
+
+**`src/handlers/async-agent-chunk-handler.ts`** — `TurnContext` gets `sessionKey`. When `registerPendingAgent` is called, the counter is incremented in the same function.
+
+**`src/handlers/message.ts`** (Telegram):
+- Computes `sessionKey` once at the top of the handler and passes it everywhere
+- `if (session.isProcessing)` branch now checks `shouldBypassQueue` first — if true, aborts + waits for cleanup + falls through to process the new message. If false, queues as before.
+- When queueing, the handler now sends a text reply (`"⏳ Eine Anfrage läuft gerade. Deine Nachricht ist in der Warteschlange..."`) in addition to the 📝 reaction, so the user sees what happened (reactions alone were too subtle)
+- New `bypassResume` variable controls whether `queryOpts.sessionId` is `null` (fresh session) or `session.sessionId` (normal resume)
+- Bridge preamble now has two modes: the existing "SDK recovery" mode that bridges fallback turns, plus a new "bypass" mode that bridges the last 10 turns when starting a fresh session mid-conversation
+- New `_bypassAbortFired` session flag + `bypassAborted` local flag ensure that the old handler silently absorbs the abort error instead of showing a confusing "request cancelled" reply, and the fresh handler's finalize/broadcast/👍 reaction path is skipped for the aborted turn
+
+### Known limitations
+
+- **Platform coverage**: bypass path is Telegram-only in v4.12.3. Slack/Discord/WhatsApp handlers (`src/handlers/platform-message.ts`) don't currently handle `tool_result` chunks at all, so async agents can't be registered on those platforms. That's a pre-existing limitation that will be fixed in a future release.
+- **SDK behavior dependency**: the fix assumes the background task's own subprocess is detached from the parent SDK query's `AbortController`. Empirically this holds (the watcher delivers results even after bypass-abort), but if a future SDK release changes this we'd need to either stop using `run_in_background` and rely on a pure Alvin-side background dispatch (bigger change) or add a targeted `process.kill` for the parent only, keeping the child alive.
+- **Restart mid-flight**: if the bot restarts while a background agent is pending, the session's counter starts at 0 on restart. The watcher re-hydrates its own state file and still delivers the result correctly, but the session's "is this blocked?" signal is lost, so the first post-restart message might use SDK resume on the old (possibly-blocked) session ID. Minor cosmetic issue, not a data loss.
+
+### Testing
+
+- **Baseline**: 396 tests (v4.12.2)
+- **New tests**: +40
+  - `test/session-pending-background.test.ts` — 4 tests (counter wiring, reset, clamp)
+  - `test/watcher-pending-count.test.ts` — 6 tests (decrement on delivery/timeout/failure, missing sessionKey, multi-agent)
+  - `test/async-agent-chunk-flow.test.ts` — +3 tests (sessionKey propagation, counter stacking, non-async no-op)
+  - `test/background-bypass.test.ts` — 12 tests (pure helpers: shouldBypassQueue, shouldBypassSdkResume, waitUntilProcessingFalse)
+  - `test/background-bypass-integration.test.ts` — 6 tests (full lifecycle, stress, session isolation)
+  - `test/background-bypass-stress.test.ts` — 9 tests (100 parallel sessions, 200 churn cycles, extreme drift, /new during pending, ephemeral session, mixed rollout, timing edge cases, high load 50×4 agents)
+- **Total**: 436 tests, all green, TSC clean
+
+### Files changed
+
+- **NEW**: `src/handlers/background-bypass.ts`
+- **NEW tests**: `test/session-pending-background.test.ts`, `test/watcher-pending-count.test.ts`, `test/background-bypass.test.ts`, `test/background-bypass-integration.test.ts`, `test/background-bypass-stress.test.ts`
+- **Modified**: `src/handlers/message.ts` (bypass wiring + visible queue reply), `src/handlers/async-agent-chunk-handler.ts` (sessionKey + counter increment), `src/services/async-agent-watcher.ts` (sessionKey in PendingAsyncAgent + decrement on delivery), `src/services/session.ts` (pendingBackgroundCount field + _bypassAbortFired flag), `src/services/session-persistence.ts` (counter not persisted — reset on restart), `test/async-agent-chunk-flow.test.ts` (new assertions)
+- **Version**: `package.json` 4.12.2 → 4.12.3
+
+---
+
+## [4.12.2] — 2026-04-15
+
+### 🔒 Security patch: file permissions, ALLOWED_USERS hard-fail, exec-guard hardening, CVE updates
+
+This is the first **formal security release** of Alvin Bot, motivated by a comprehensive audit after v4.12.1 production deployment. The audit surfaced real issues that needed fixing before the bot could be safely installed on multi-user dev servers or shared by external users. All fixes are additive and backwards-compatible — existing single-user installs see no behavior change except improved security.
+
+#### CRITICAL CVE — axios 1.14.0 → 1.15.0 (CVSS 10.0)
+
+Transitive dependency via `@slack/bolt`. Two CVEs closed:
+- GHSA-fvcv-3m26-pcqx — Cloud Metadata Exfiltration via Header Injection Chain (CVSS 10.0)
+- GHSA-3p68-rc4w-qgx5 — NO_PROXY Hostname Normalization Bypass → SSRF
+
+Fix: `npm update @slack/bolt` (4.6.0 → 4.7.0) + `package.json overrides: axios ^1.15.0` to force transitive updates in `@slack/web-api` and `@whiskeysockets/baileys`. Post-fix `npm audit` shows **0 critical, 2 high remaining** (`basic-ftp` HIGH — never invoked by Alvin, `electron` HIGH — devDep only, tracked as Phase 18).
+
+Also updated `@anthropic-ai/claude-agent-sdk` 0.2.97 → 0.2.109 (MODERATE: GHSA-5474-4w2j-mq4c Path Validation Sandbox Escape).
+
+#### CRITICAL — File permissions on sensitive files (0o600)
+
+Pre-v4.12.2 `~/.alvin-bot/.env`, `state/sessions.json`, memory logs, cron-jobs.json were written with the default umask — typically 0o644 on Linux/macOS, meaning any other user on the same machine could read BOT_TOKEN + all API keys, full conversation history, cron prompts, and encrypted sudo credentials.
+
+**Fix**: new `src/services/file-permissions.ts` with `writeSecure()`, `ensureSecureMode()`, `auditSensitiveFiles()`. All `.env` writes in setup-api, doctor-api, server, fallback-order, session-persistence now use `writeSecure()`. Startup audit in `index.ts` chmod-repairs the full sensitive-file list idempotently on every boot.
+
+#### CRITICAL — ALLOWED_USERS startup hard-fail
+
+Pre-v4.12.2 Alvin started with BOT_TOKEN set but ALLOWED_USERS empty with only a console.warn — leaving the bot "configured but unguarded".
+
+**Fix**: new pure gate function `src/services/allowed-users-gate.ts`. `src/index.ts` refuses to start with a clear error message. Two explicit escape hatches: `AUTH_MODE=open` or `ALVIN_INSECURE_ACKNOWLEDGED=1`.
+
+#### HIGH — Webhook bearer token timing-safe comparison
+
+`src/web/server.ts` POST /api/webhook previously used naive `authHeader !== "Bearer " + token` leaking comparison position via timing side-channel.
+
+**Fix**: new `src/services/timing-safe-bearer.ts` wraps `crypto.timingSafeEqual` with strict "Bearer <token>" format, empty-expected rejection, length-mismatch dummy comparison.
+
+#### HIGH — Exec-guard shell metacharacter rejection
+
+`checkExecAllowed()` only inspected the first word — `echo safe; rm -rf /` passed as "echo". Trivially bypassable via `&&`, `|`, `` ` ``, `$(...)`, redirects.
+
+**Fix**: allowlist mode rejects any command containing `;`, `&`, `|`, `` ` ``, `$(...)`, `{...}`, `<`, `>`. Operators who need shell pipelines set `EXEC_SECURITY=full` explicitly.
+
+#### HIGH — Cron shell-job execGuard integration
+
+Pre-v4.12.2 cron `type: "shell"` bypassed the exec-guard entirely. **Fix**: cron.ts case "shell" now calls `checkExecAllowed()` before `execSync()` and sends a blocked-notification on deny.
+
+#### MEDIUM — Sub-agent toolset allowlist (readonly, research)
+
+`SubAgentConfig.toolset` widened from `"full"` to `"full" | "readonly" | "research"`:
+- `readonly` → Read, Glob, Grep only (no write, shell, network)
+- `research` → readonly + WebSearch, WebFetch
+- `full` → unchanged default
+
+New `QueryOptions.allowedTools?: string[]` honored by `claude-sdk-provider`. Other providers ignore it.
+
+#### NEW — `docs/security.md` threat model + hardening guide (279 lines)
+
+First formal security documentation covering: TL;DR safety table, capability surface, attacker model, trust boundaries, hardening step-by-step, shell execution policy, file permissions list, sub-agent presets, prompt injection honesty section, Phase 18 pending work, security issue reporting, incident response playbook. Public doc, shipped with the repo.
+
+#### NEW — README Security section rewrite
+
+Replaced thin bullet list with a boxed warning ("Alvin has full shell + filesystem access") and four sub-sections: access control, execution hardening, data hardening, known limitations. Links to docs/security.md.
+
+#### Testing
+
+**396 tests total** (350 baseline from v4.12.1 + 46 new). All green. Build clean.
+
+- 10 `test/file-permissions.test.ts`
+- 7 `test/allowed-users-gate.test.ts`
+- 10 `test/timing-safe-bearer.test.ts`
+- 13 `test/exec-guard-metachars.test.ts`
+- 4 `test/subagent-toolset-allowlist.test.ts`
+- 2 extended `test/subagents-toolset.test.ts` (readonly + research)
+
+#### Phase 18 (deferred, tracked in README Roadmap)
+
+- Electron 35 → 41+ upgrade (Desktop build, 6 CVEs)
+- Prompt injection defense strategy (design debate, not code filter)
+- TypeScript 5 → 6 upgrade
+- MCP plugin sandboxing (architectural v5.0)
+
+---
+
 ## [4.12.1] — 2026-04-15
 
 ### 🐛 Patch: Sync sub-agent timeout + workspace command menu

package/README.md

@@ -659,17 +659,54 @@ alvin-bot version   # Show version
   - [ ] Workspace cloning / templates — `/workspace clone alev-b as homes-dev` spins up a new workspace from an existing one
   - [ ] Slack slash commands (`/alvin workspace`, `/alvin status`, `/alvin new`) — native Slack command integration via Bolt
   - [ ] Daily log decay / archive — older daily logs move to cold storage after N days
+- [ ] **Phase 18** — Security + Platform hardening (from v4.12.1 audit, prioritized)
+  - [ ] **P1 — Electron major upgrade** (35 → 41+) — fixes 1 HIGH + 5 MODERATE Electron CVEs in the Desktop-Build path. Major version jump, requires full rebuild + test of `.dmg` flow. Separate release (likely bundled with Windows `.exe` work).
+  - [ ] **P1 — Prompt injection defense strategy** — not a single fix but a design debate: heuristic filters vs allow-list vs no-sandbox-accept-the-risk. Currently handled as a documented design-constraint (README security section), not as a code filter. When we decide the policy, implement it across all message entry points.
+  - [ ] **P2 — TypeScript 5 → 6 upgrade** — major release, likely breaking changes in strict mode. Needs a dedicated release + test sweep. Low priority since 5.x is still supported.
+  - [ ] **P0 for v5.0 — MCP plugin sandboxing** — currently MCP servers run with full Node privileges. Plan: run each MCP in a child process with restricted FS + network policy (similar to deno-permission model). Architectural change, v5.0 territory.
 
 ---
 
 ## 🔒 Security
 
-- **User whitelist** — Only `ALLOWED_USERS` can interact with the bot
+> ### ⚠️ Important: Alvin has full shell + filesystem access
+>
+> Alvin Bot is an **autonomous AI agent** built on the Claude Agent SDK with shell, filesystem, and network access to the machine it runs on. This is by design — it's the point of the project. But it means:
+>
+> - **Treat the bot like `sudo` access** — only install it on machines where you'd trust Claude Code to run without supervision.
+> - **Never expose the Web UI (port 3100) to the internet** without HTTPS, rate limiting, and a strong `WEB_PASSWORD`. It binds to `localhost` by default.
+> - **On multi-user systems**, verify `~/.alvin-bot/.env` is chmod `600` (v4.12.2+ enforces this automatically on startup).
+> - **`ALLOWED_USERS` is your first line of defense** — v4.12.2+ refuses to start if it's empty and Telegram is enabled.
+>
+> **Read the full threat model and hardening guide:** [`docs/security.md`](docs/security.md)
+
+### Access control
+
+- **User whitelist** — Only `ALLOWED_USERS` can interact with the bot (hard-enforced at startup since v4.12.2)
 - **WhatsApp group approval** — Per-group participant whitelist + owner approval gate via Telegram (with WhatsApp DM / Discord / Signal fallback). Group members never see the approval process.
-- **Self-hosted** — Your data stays on your machine
-- **No telemetry** — Zero tracking, zero analytics, zero phone-home
-- **Web UI auth** — Optional password protection for the dashboard
-- **Owner protection** — Owner account cannot be deleted via UI
+- **Slack allowlist** — `SLACK_ALLOWED_USERS` restricts who can DM or @mention the bot in Slack
+- **DM pairing** — Optional 6-digit code flow for new users via owner approval (`AUTH_MODE=pairing`)
+
+### Execution hardening
+
+- **`EXEC_SECURITY=allowlist`** (default) — Shell commands must match a whitelist of safe binaries and **cannot contain shell metacharacters** (`;`, `|`, `&`, `` ` ``, `$(...)`, redirects). Rejected by v4.12.2's exec-guard metachar filter.
+- **Cron shell jobs** go through the same exec-guard (v4.12.2+) — cron is no longer a bypass vector.
+- **Sub-agent toolset presets** — spawn sub-agents with `toolset: "readonly"` or `"research"` to restrict what they can do, regardless of the parent's privileges.
+- **Timing-safe webhook auth** — `POST /api/webhook` uses `crypto.timingSafeEqual` (v4.12.2+) to prevent timing side-channel token extraction.
+
+### Data hardening
+
+- **Self-hosted** — Your data stays on your machine. No cloud sync, no external logging of prompts or responses.
+- **No telemetry** — Zero tracking, zero analytics, zero phone-home.
+- **File permissions** — `.env`, `sessions.json`, memory logs, cron jobs, and all sensitive state files are chmod `0o600` on every write and repaired at startup (v4.12.2+).
+- **Owner protection** — Owner account cannot be deleted via UI.
+- **Encrypted sudo credentials** — If you enable sudo exec, passwords are stored encrypted with an XOR key in a separate file, both chmod `0o600`.
+
+### Known limitations (documented honestly)
+
+- **Prompt injection** cannot be reliably filtered — we document this as a capability tradeoff rather than pretending to solve it. See `docs/security.md` for the full discussion.
+- **Not yet hardened for public-internet deployment** — current scope is "on your own machine". VPS deployment works but requires additional reverse-proxy + TLS + rate-limit setup that we don't automate.
+- **Electron Desktop build** has known CVEs (Phase 18 roadmap). The primary distribution is npm global install, not Desktop — if you don't use the Desktop wrapper, you're not affected.
 
 ---
 

package/dist/handlers/async-agent-chunk-handler.js

@@ -1,5 +1,6 @@
 import { parseAsyncLaunchedToolResult } from "../services/async-agent-parser.js";
 import { registerPendingAgent } from "../services/async-agent-watcher.js";
+import { getAllSessions } from "../services/session.js";
 /**
  * Inspect a stream chunk; if it's an Agent async_launched tool_result,
  * register the pending agent with the watcher.
@@ -29,5 +30,21 @@ export function handleToolResultChunk(chunk, ctx) {
         chatId: ctx.chatId,
         userId: ctx.userId,
         toolUseId: chunk.toolUseId ?? null,
+        sessionKey: ctx.sessionKey,
     });
+    // v4.12.3 — Increment the session's pendingBackgroundCount so the
+    // main handler knows a background task is tying up the SDK's CLI
+    // subprocess. The watcher decrements this when it delivers the result.
+    // Guarded: missing sessionKey or unknown session is a no-op.
+    if (ctx.sessionKey) {
+        try {
+            const s = getAllSessions().get(ctx.sessionKey);
+            if (s) {
+                s.pendingBackgroundCount = (s.pendingBackgroundCount ?? 0) + 1;
+            }
+        }
+        catch {
+            /* never let counter updates break registration */
+        }
+    }
 }

package/dist/handlers/background-bypass.js

@@ -0,0 +1,75 @@
+/**
+ * v4.12.3 — Background-agent bypass helpers.
+ *
+ * Pure state-machine helpers used by the Telegram + platform message
+ * handlers to decide whether to:
+ *   1. Abort a running query instead of queueing the next user message,
+ *      when the running query is blocked waiting for a background
+ *      task-notification (SDK's CLI subprocess stays alive for the full
+ *      duration of the background task).
+ *   2. Start the next SDK query with a fresh session (sessionId=null)
+ *      when any background agent is still pending, so the new query
+ *      doesn't inherit the old session's block.
+ *
+ * These are separated into their own module so they can be unit tested
+ * without a grammy Context mock.
+ */
+/**
+ * Decide whether to bypass the normal "queue this message" branch and
+ * interrupt the running query so the new message can proceed immediately.
+ *
+ * True when:
+ *   - A query is currently running (`isProcessing`)
+ *   - At least one background agent is pending in this session
+ *   - An unaborted abortController exists to cancel the running query
+ *
+ * Otherwise false → fall back to the normal queue/drop behavior.
+ */
+export function shouldBypassQueue(state) {
+    if (!state.isProcessing)
+        return false;
+    if (state.pendingBackgroundCount <= 0)
+        return false;
+    const ac = state.abortController;
+    if (!ac)
+        return false;
+    if (ac.signal.aborted)
+        return false;
+    return true;
+}
+/**
+ * Decide whether the next SDK query should skip `resume: sessionId`
+ * and start a fresh session instead. Needed when a background agent is
+ * still pending — resuming the original session would inherit its block
+ * (the SDK's CLI subprocess for that session is waiting to deliver the
+ * task-notification inline). A fresh session has no such block and
+ * proceeds immediately. Context is preserved via the bridge preamble
+ * (buildBridgeMessage in message.ts).
+ */
+export function shouldBypassSdkResume(state) {
+    return state.pendingBackgroundCount > 0;
+}
+/**
+ * Poll-wait until `session.isProcessing` becomes false (or the timeout
+ * elapses). Returns true if the flag flipped, false on timeout.
+ *
+ * Used by the bypass path: after calling `abort()` on the running query,
+ * we wait for its finally block to run and flip isProcessing=false
+ * before starting the new query. The handler's own message loop is the
+ * one flipping the flag, so we just have to yield the event loop and
+ * re-check.
+ *
+ * Timeouts above 0 are recommended. Default tick interval is 50ms which
+ * is short enough that the fall-through feels instant to the user.
+ */
+export async function waitUntilProcessingFalse(session, timeoutMs, tickMs = 50) {
+    if (!session.isProcessing)
+        return true;
+    const start = Date.now();
+    while (session.isProcessing) {
+        if (Date.now() - start >= timeoutMs)
+            return false;
+        await new Promise((resolve) => setTimeout(resolve, tickMs));
+    }
+    return true;
+}

package/dist/handlers/message.js

@@ -18,6 +18,7 @@ import { t } from "../i18n.js";
 import { isHarmlessTelegramError } from "../util/telegram-error-filter.js";
 import { handleToolResultChunk } from "./async-agent-chunk-handler.js";
 import { createStuckTimer } from "./stuck-timer.js";
+import { shouldBypassQueue, shouldBypassSdkResume, waitUntilProcessingFalse, } from "./background-bypass.js";
 /**
  * Stuck-only timeout — NO absolute cap.
  *
@@ -152,7 +153,8 @@ export async function handleMessage(ctx) {
         text = `[Replying to previous message: "${quotedText}"]\n\n${text}`;
     }
     const userId = ctx.from.id;
-    const session = getSession(buildSessionKey("telegram", ctx.chat.id, userId));
+    const sessionKey = buildSessionKey("telegram", ctx.chat.id, userId);
+    const session = getSession(sessionKey);
     // Track user profile
     touchProfile(userId, ctx.from?.first_name, ctx.from?.username, "telegram", text);
     // Sync session language from persistent profile (on first message)
@@ -163,15 +165,54 @@ export async function handleMessage(ctx) {
             session.language = profile.language;
     }
     if (session.isProcessing) {
-        // Queue the message instead of rejecting it (max 3)
-        if (session.messageQueue.length < 3) {
-            session.messageQueue.push(text);
-            await react(ctx, "📝");
+        // v4.12.3 — If a background agent is pending, the running query is
+        // almost certainly just the SDK's CLI subprocess sitting idle waiting
+        // for the task-notification to be ready (can take 5+ minutes for long
+        // audits). Don't queue — abort the blocked query and fall through so
+        // the new message gets processed immediately. The background task
+        // itself continues in its detached subprocess; the async-agent watcher
+        // delivers the result via subagent-delivery.ts when ready.
+        if (shouldBypassQueue({
+            isProcessing: session.isProcessing,
+            pendingBackgroundCount: session.pendingBackgroundCount,
+            abortController: session.abortController,
+        })) {
+            console.log(`[v4.12.3 bypass] aborting blocked query for ${sessionKey} — ` +
+                `${session.pendingBackgroundCount} background agent(s) pending`);
+            // Mark the abort as a bypass so the old handler's error branch
+            // doesn't surface a "request cancelled" reply to the user.
+            session._bypassAbortFired = true;
+            try {
+                session.abortController.abort();
+            }
+            catch {
+                /* ignore */
+            }
+            // Wait briefly for the old handler's finally to run. If it hangs
+            // (>5s, shouldn't happen), we fall through anyway — worst case is
+            // a brief overlap where both handlers run.
+            await waitUntilProcessingFalse(session, 5000);
+            // Fall through to start a fresh query below.
         }
         else {
-            await ctx.reply("⏳ Warteschlange voll (3 Nachrichten). Bitte warten oder /cancel.");
+            // Normal queue behavior. v4.12.3 — emit a text reply in addition
+            // to the reaction so the user actually sees that their message
+            // was received and is waiting. Reactions alone are too subtle.
+            if (session.messageQueue.length < 3) {
+                session.messageQueue.push(text);
+                await react(ctx, "📝");
+                try {
+                    await ctx.reply("⏳ Eine Anfrage läuft gerade. Deine Nachricht ist in der Warteschlange und wird als Nächstes bearbeitet.");
+                }
+                catch {
+                    /* harmless grammy race */
+                }
+            }
+            else {
+                await ctx.reply("⏳ Warteschlange voll (3 Nachrichten). Bitte warten oder /cancel.");
+            }
+            return;
         }
-        return;
     }
     // Consume queued messages (sent while previous query was processing)
     if (session.messageQueue.length > 0) {
@@ -180,9 +221,23 @@ export async function handleMessage(ctx) {
     }
     session.isProcessing = true;
     session.abortController = new AbortController();
+    // v4.12.3 — Clear any stale bypass flag from a previous aborted turn.
+    // The flag is set by the bypass path right before it calls abort(),
+    // read by the OLD handler's error path, and cleared here by the NEW
+    // handler so it doesn't misclassify future non-bypass aborts. Use
+    // `delete` so TypeScript doesn't narrow the flag to literal `false`
+    // for the rest of this function (it's mutated from the bypass path in
+    // another handler invocation, so the type stays `boolean | undefined`).
+    delete session._bypassAbortFired;
     const streamer = new TelegramStreamer(ctx.chat.id, ctx.api, ctx.message?.message_id);
     let finalText = "";
     let timedOut = false;
+    // v4.12.3 — Tracks whether the current turn ended because the bypass
+    // path aborted us. When true, skip the finalize/broadcast/👍 reaction
+    // flow at the bottom of the handler since the user isn't waiting on
+    // this turn anymore. Explicit `boolean` type so TS doesn't narrow to
+    // the literal `false` and reject the later comparison.
+    let bypassAborted = false;
     const typingInterval = setInterval(() => {
         ctx.api.sendChatAction(ctx.chat.id, "typing").catch(() => { });
     }, 4000);
@@ -280,22 +335,49 @@ export async function handleMessage(ctx) {
                 session.checkpointHintsInjected++;
             }
         }
+        // v4.12.3 — If a background agent is still pending, skip SDK resume.
+        // The OLD SDK session is blocked waiting to deliver the
+        // task-notification inline; resuming it would inherit that block.
+        // Start a fresh SDK session and rely on the bridge preamble below
+        // to carry recent history so Claude has context.
+        const bypassResume = isSDK && shouldBypassSdkResume({
+            pendingBackgroundCount: session.pendingBackgroundCount,
+        });
+        if (bypassResume) {
+            console.log(`[v4.12.3 bypass] starting fresh SDK session for ${sessionKey} — ` +
+                `${session.pendingBackgroundCount} background agent(s) still pending`);
+        }
         // B2 Bridge-Message: if SDK is active but there are non-SDK turns since
         // the last SDK turn, prepend a catch-up preamble so the SDK sees what
         // happened during the failover. We defensively clamp the index against
         // history bounds in case compaction shrank the array under our feet.
+        //
+        // v4.12.3 — Bypass-resume path also gets a bridge: since we're starting
+        // a fresh SDK session, Claude has no prior context from this chat.
+        // Bridge the last BYPASS_BRIDGE_TURNS entries so it knows what we were
+        // just talking about.
+        const BYPASS_BRIDGE_TURNS = 10;
         let bridgedPrompt = text;
         if (isSDK) {
-            const anchor = Math.min(session.lastSdkHistoryIndex, session.history.length - 1);
-            const gapStart = Math.max(0, anchor + 1);
-            // gapEnd excludes the user message we just added (history.length - 1).
-            const gapEnd = session.history.length - 1;
+            let gapStart;
+            let gapEnd;
+            if (bypassResume) {
+                gapEnd = session.history.length - 1;
+                gapStart = Math.max(0, gapEnd - BYPASS_BRIDGE_TURNS);
+            }
+            else {
+                const anchor = Math.min(session.lastSdkHistoryIndex, session.history.length - 1);
+                gapStart = Math.max(0, anchor + 1);
+                // gapEnd excludes the user message we just added (history.length - 1).
+                gapEnd = session.history.length - 1;
+            }
             if (gapEnd > gapStart) {
                 const gapTurns = session.history.slice(gapStart, gapEnd);
                 const bridge = buildBridgeMessage(gapTurns);
                 if (bridge) {
                     bridgedPrompt = bridge + text;
-                    console.log(`[bridge] SDK recovery: injecting ${gapTurns.length} fallback turn(s) into prompt`);
+                    console.log(`[bridge] ${bypassResume ? "bypass" : "SDK recovery"}: ` +
+                        `injecting ${gapTurns.length} turn(s) into prompt`);
                 }
             }
         }
@@ -307,8 +389,8 @@ export async function handleMessage(ctx) {
             abortSignal: session.abortController.signal,
             // User's UI locale — registry uses it to localize failure messages.
             locale: session.language,
-            // SDK-specific
-            sessionId: isSDK ? session.sessionId : null,
+            // SDK-specific. v4.12.3 — bypass resume when background pending.
+            sessionId: isSDK && !bypassResume ? session.sessionId : null,
             // Unified history: SDK ignores it (uses filesystem-resume instead),
             // non-SDK providers use it for context. Keeping it populated for both
             // means a failover from SDK → Ollama keeps the conversation context.
@@ -418,9 +500,12 @@ export async function handleMessage(ctx) {
                     // hand them off to the async-agent watcher. The watcher will
                     // poll the outputFile and deliver the result as a separate
                     // Telegram message when the background agent finishes.
+                    // v4.12.3 — Forward sessionKey so the watcher can route the
+                    // delivery-complete decrement back to the right session.
                     handleToolResultChunk(chunk, {
                         chatId: ctx.chat.id,
                         userId,
+                        sessionKey,
                         lastToolUseInput: lastAgentToolUseInput,
                     });
                     // Reset the captured input — only the immediately following
@@ -447,6 +532,15 @@ export async function handleMessage(ctx) {
                     await ctx.reply(`⚡ _${chunk.failedProvider} unavailable — switching to ${chunk.providerName}_`, { parse_mode: "Markdown" });
                     break;
                 case "error":
+                    // v4.12.3 — If the bypass path aborted us, swallow the error
+                    // silently. The new handler is already preparing to process
+                    // the user's next message; showing a cancellation notice here
+                    // would be misleading.
+                    if (session._bypassAbortFired === true &&
+                        chunk.error?.toLowerCase().includes("abort")) {
+                        bypassAborted = true;
+                        break;
+                    }
                     // If our stuck-timer fired, the abort travels up as a registry
                     // mid-stream error chunk. Prefer the explicit stuck message over
                     // the generic one so the user understands this was a real hang,
@@ -460,6 +554,11 @@ export async function handleMessage(ctx) {
                     break;
             }
         }
+        if (bypassAborted) {
+            // v4.12.3 — Bypass path took over; don't finalize, don't react 👍.
+            // Just clean up and return. The finally block still fires.
+            return;
+        }
         await streamer.finalize(finalText);
         emit("message:sent", { userId, text: finalText, platform: "telegram" });
         // v4.5.0: tell observers the response is complete.
@@ -499,14 +598,26 @@ export async function handleMessage(ctx) {
     catch (err) {
         const errorMsg = err instanceof Error ? err.message : String(err);
         const lang = session.language;
-        await react(ctx, "👎");
-        if (timedOut) {
+        // v4.12.3 — If this handler was interrupted by the bypass path
+        // (another handler aborted us to process a new message while a
+        // background agent is pending), silently absorb the abort error.
+        // Showing "request cancelled" would be misleading — from the
+        // user's point of view, nothing was cancelled, their new message
+        // is just being processed.
+        const absorbBypassAbort = errorMsg.includes("abort") && session._bypassAbortFired === true;
+        if (absorbBypassAbort) {
+            // Do NOT react 👎 or reply — just clean up silently.
+        }
+        else if (timedOut) {
+            await react(ctx, "👎");
             await ctx.reply(t("bot.error.timeoutStuck", lang, { min: STUCK_TIMEOUT_MINUTES }));
         }
         else if (errorMsg.includes("abort")) {
+            await react(ctx, "👎");
             await ctx.reply(t("bot.error.requestCancelled", lang));
         }
         else if (!isHarmlessTelegramError(err)) {
+            await react(ctx, "👎");
             // Drop benign grammy races ("message is not modified", etc.)
             // instead of surfacing them as "Fehler: ..." replies.
             await ctx.reply(`${t("bot.error.prefix", lang)} ${errorMsg}`);

package/dist/index.js

@@ -20,6 +20,57 @@ if (hasLegacyData()) {
 }
 // 3. Seed defaults for any files that don't exist yet (fresh install)
 seedDefaults();
+// 3a. v4.12.2 — Audit + repair permissions on sensitive files. On multi-user
+//     systems, files written pre-v4.12.2 may have 0o644 / 0o666 mode — i.e.
+//     readable by other users on the same machine. This routine chmod-repairs
+//     them to 0o600 (owner read/write only) at every startup. Idempotent for
+//     already-secure files; silent no-op for missing files.
+import { auditSensitiveFiles } from "./services/file-permissions.js";
+import { ENV_FILE as SEC_ENV, SESSIONS_STATE_FILE, MEMORY_FILE, CRON_FILE as SEC_CRON } from "./paths.js";
+import { readdirSync } from "fs";
+import { resolve as pathResolve } from "path";
+import { MEMORY_DIR as SEC_MEM_DIR, DATA_DIR as SEC_DATA_DIR } from "./paths.js";
+{
+    const sensitivePaths = [SEC_ENV, SESSIONS_STATE_FILE, MEMORY_FILE, SEC_CRON];
+    // Also audit every daily-log markdown file — they contain full conversation history
+    try {
+        if (readdirSync.length !== undefined) {
+            for (const entry of readdirSync(SEC_MEM_DIR)) {
+                if (entry.endsWith(".md") && !entry.startsWith(".")) {
+                    sensitivePaths.push(pathResolve(SEC_MEM_DIR, entry));
+                }
+            }
+        }
+    }
+    catch {
+        // memory dir missing — fine
+    }
+    // Also include async-agents state, delivery queue, and sudo credentials
+    const optionalPaths = [
+        pathResolve(SEC_DATA_DIR, "state", "async-agents.json"),
+        pathResolve(SEC_DATA_DIR, "delivery-queue.json"),
+        pathResolve(SEC_DATA_DIR, "data", ".sudo-enc"),
+        pathResolve(SEC_DATA_DIR, "data", ".sudo-key"),
+        pathResolve(SEC_DATA_DIR, "data", "access.json"),
+        pathResolve(SEC_DATA_DIR, "data", "approved-users.json"),
+    ];
+    sensitivePaths.push(...optionalPaths);
+    const auditResults = auditSensitiveFiles(sensitivePaths);
+    const repaired = auditResults.filter(r => r.status === "repaired");
+    if (repaired.length > 0) {
+        console.log(`🔒 file-permissions: repaired ${repaired.length} sensitive file(s) to 0o600`);
+        for (const r of repaired) {
+            console.log(`   ${r.path} (was 0o${r.previousMode})`);
+        }
+    }
+    const errors = auditResults.filter(r => r.status === "error");
+    if (errors.length > 0) {
+        console.warn(`⚠️  file-permissions: ${errors.length} file(s) could not be repaired:`);
+        for (const r of errors) {
+            console.warn(`   ${r.path}: ${r.error}`);
+        }
+    }
+}
 // 4. Crash-loop brake check — if we've crashed N times in a short window,
 //    refuse to start, write an alert file, and unload our LaunchAgent so
 //    launchd stops retrying. Runs BEFORE any expensive init so a broken
@@ -35,9 +86,30 @@ if (!hasTelegram) {
     console.warn("⚠️  BOT_TOKEN not set — Telegram disabled. WebUI + Cron still active.");
     console.warn("   Run 'alvin-bot setup' or set BOT_TOKEN in ~/.alvin-bot/.env");
 }
-if (config.allowedUsers.length === 0 && hasTelegram) {
-    console.warn("⚠️  ALLOWED_USERS not set — nobody can message the Telegram bot yet.");
-    console.warn("   Send /start to @userinfobot on Telegram to find your ID.");
+// v4.12.2 — ALLOWED_USERS startup gate. Refuses to start when Telegram is
+// configured but no user allowlist is set, because that would leave the bot
+// open to any Telegram user with full shell/filesystem access via prompt
+// injection. See src/services/allowed-users-gate.ts for the pure decision
+// function + tests.
+{
+    const { checkAllowedUsersGate } = await import("./services/allowed-users-gate.js");
+    const gate = checkAllowedUsersGate({
+        hasTelegram,
+        allowedUsersCount: config.allowedUsers.length,
+        authMode: config.authMode,
+        insecureAcknowledged: process.env.ALVIN_INSECURE_ACKNOWLEDGED === "1",
+    });
+    if (!gate.allowed) {
+        console.error("");
+        console.error("❌ CRITICAL: Alvin Bot refusing to start.");
+        console.error("");
+        console.error("   " + gate.reason);
+        console.error("");
+        process.exit(1);
+    }
+    if (gate.warning) {
+        console.warn("⚠️  " + gate.warning);
+    }
 }
 // Check if the chosen provider has a corresponding API key.
 // Keys here MUST match the registry keys from src/providers/registry.ts