Mockup 01 · Option 2No-Docker architecture
(two-box, claude -c -p per turn)

The platonic ideal realized with two small Linux boxes and one HTTPS call to noos. No Docker. No Kubernetes. No tmux. No long-lived REPLs. A small bot server handles the channel and routing; a separate little machine is where Claude actually runs, one SSH-exec per turn.

UX is the same as the platonic ideal. This page focuses on the mechanical architecture. For the user-facing scenes (attention, consent loop, manifest dialog, reactions), see Mockup 00.

1The machines

2What lives where

3Concrete consent-loop turn (wire view)

1. A · inbound webhook. Linq POSTs message.received for "is jacob free tuesday?" to https://picortex.globalbr.ai/api/linq/inbound. HMAC verified. Row inserted in messages on A's SQLite.
2. A · attention gate passes (@mention detected). A · Turn dispatcher checks the chat's manifest row: calendar not in scope.
3. A · consent broker activates. Inserts DisclosureEvent (approval_mode: pending, ttl_expires_at: +10min). Sends group ack via Linq sendMessage: "Let me check with him — one sec." Typing indicator on.
4. A · out-of-band DM to Jacob via Linq sendMessage with full context + proposed response + approve/deny keys.
5. A · Jacob replies y. Broker matches to the pending DisclosureEvent, marks approval_mode: approve-exact, expands turn scope to include calendar:2026-04-28T19:00/21:00.
6. A → B · SSH. Turn dispatcher opens SSH to box B:
   ssh -i /etc/picortex/keys/b_admin.pem picortex@B
sudo -u chat-a1b2 -H claude --session-id chat-a1b2 -p "<system+context+prompt>"
7. B · Claude runs. Reads ~/.claude/sessions/chat-a1b2/ for prior turns on this chat. Calls optional noos MCP tool to check calendar. stdout = proposed reply.
8. A · outbound. Bot server receives stdout over SSH, writes to SQLite, sends final reply to group via Linq sendMessage. Closes DisclosureEvent with final_reply + grant_ttl: single-use.

4Code sketch (bot server's executor)

// boxA/src/executor.ts — per-turn dispatcher (Option 2 · No-Docker)
import { SSHClient } from './ssh.js'
import { scopedCtx } from './manifest.js'

export async function executeTurn(chat: Chat, message: Message, scope: Scope) {
  const turnId = ulid()
  const ctxSystem = buildSystemPrompt(chat, scope)   // manifest-filtered
  const prompt = formatTurnInput(message)

  // One SSH exec per turn. No tmux, no sentinels.
  const { stdout, code } = await ssh.execAsUser(
    chat.unix_user,
    ['claude', '--session-id', chat.id, '-p', '--dangerously-skip-permissions', '--system', ctxSystem, prompt],
    { env: { PICORTEX_TURN_ID: turnId }, timeout_ms: 120_000 },
  )

  if (code !== 0) return replyFailure(stdout)
  return recordAndSend(chat, stdout, { turnId })
}

Consent broker — pause/resume

// On pause: write DisclosureEvent row, send DM, return to event loop.
// On Jacob's reply: match by (jacob_dm_chat_id, in-flight-row), re-invoke executeTurn with expanded scope.
// On timeout: clear row, send group "I need to check on that offline", log approval_mode="timeout".

5Strengths & costs, head-to-head

6Five failure modes & what happens

7Why this might be the answer

8What this doesn't solve

• Does not protect against a compromised noos (box C) leaking data. That's a separate trust boundary.
• Does not eliminate shared-kernel risk on B. If the D2 isolation report finds Linux-user perms insufficient for the real threat model, B's per-chat users get wrapped in bubblewrap or Landlock — composes naturally, no re-architecture.
• Does not give you an ephemeral per-chat machine (Option 3). If that becomes the real privacy requirement, B's per-chat users are replaced with Fly Machines per chat.

Compare with the platonic ideal, the stateless Option 4, or what Piyush actually shipped.