Prototype options — brainstorm

Date: 2026-04-23 Status: Brainstorm — NOT a plan. Questions are in [beads: picortex-Q*].

Reframing acknowledged: the product is awesome 1:1 and group texting with a brain. Claude Code vs OpenClaw vs SSH-to-remote is just an implementation detail of the brain. Development surfaces (terminal, file browser) are optional convenience, not the point.

The shape of the answer (decision axes)

Every prototype option is a point in this 6-axis space. We pick coordinates per axis, then a concrete option is a bundle of choices.

Option cards

Six concrete bundles Jacob asked about. Each card's header lists its coordinates in axes A-F.

Option 1 — "Current picortex"

(A=1-box, B=per-chat, C=tmux+Claude-Code, D=tmux-process, E=none, F=terminal+browser)

• All on one VPS. Per-chat Linux user + home dir + long-lived tmux session + Claude Code REPL.
• Reply capture via sentinel protocol.
• Covered in detail by docs/prd/001-picortex-v1.md, specs 001-008.

Pros. Self-contained single deploy. Everything Cortex-like on one box. Cons. Codex's review flagged five problems here: reply-capture fragility, S3 anti-pattern, broad sudoers, unproven tmux scraping, missing S1.5 schema. Bot compromise = workspace access. Does not support the "remote box for privacy" intuition. Best for. Single-user, single-host demo. Tolerable if Jacob is fine with bot+workspace colocation.

Option 2 — "Piyush-style" (two-box, per-user, claude -c -p)

(A=2-box, B=per-user, C=claude-c-p, D=claude's --session-id, E=none, F=terminal+browser)

• Bot on one box. Workspace host is a separate box (EC2, Hetzner, Fly Machine, etc.). Bot SSHes in as the chat's Linux user and runs claude --session-id <chat_id> -p "<text>" per turn.
• See docs/wiki/piyush-era-design.md for the design study.

Pros. Clean physical separation ("remote box for privacy"). No tmux or sentinels — Claude CLI manages its own session. Bot can crash/redeploy freely; session memory persists in ~/.claude/ on the workspace host. Sudoers scope is tighter (useradd/del/chmod only). Cons. Two boxes to maintain. SSH setup overhead. -c is global-per-user in Claude CLI; need --session-id (Claude ≥ 1.0) for per-chat continuity. Group-text behavior not natively modeled — must still design that. Best for. The natural MVP if texting-first is the product. This is probably where the real v0.1 should land.

Option 3 — "Ephemeral per-chat remote container" (privacy-maxed)

(A=N-boxes, B=per-chat, C=claude-c-p, D=claude's --session-id, E=optional, F=optional)

• Per-chat Fly Machine (or Hetzner ephemeral, or Modal, or E2B sandbox). Spin up on first inbound, idle-destroy after N minutes.
• Bot exec's into the container per turn.

Pros. Strongest isolation: each chat is in its own VM / container with its own kernel-level boundaries. Compromise is bounded to that chat's ephemeral compute. "Goes away" when chat is over. Cons. Highest spin-up latency (target 10-30 s cold). Highest $/chat (each idle chat is some baseline compute). Persistence needs external volume (S3, Fly volume). Managing N machines adds ops complexity. Best for. If threat model includes "group members I don't fully trust + bot might be tricked into shell commands." Strong privacy posture for Jacob + select collaborators.

Option 4 — "noos-style" (ephemeral per turn, no workspace)

(A=1-box-or-2-box, B=per-turn, C=claude-c-p, D=backend-owned-transcript, E=noos-graph, F=none)

• No persistent workspace. Each turn: bot owns the full transcript, re-feeds claude --print with the last N messages as context. Optional tool-use via MCP to query noos graph.
• This is essentially what ~/code/noos/src/slack/ already does for Slack.

Pros. Statelessness. No Linux users. No home dirs. No SSH. Trivial to deploy, trivial to redeploy. Perfect for a pure-texting experience where "Claude as a person" suffices. Cons. No code-execution workspace means Claude can't edit/run files on Jacob's behalf. No terminal. If the use case grows into "also help me run commands on a box," we'd migrate to Option 2 or 3. Best for. The "just texting" MVP. Fastest to ship. Easiest to iterate attention gating / threading / groups on.

Option 5 — "OpenClaw with reversed policy" (use-what-exists)

(A=1-box, B=per-binding, C=OpenClaw-runtime, D=OpenClaw-sessions, E=OpenClaw-skills-or-noos, F=OpenClaw-web-console)

• Adopt OpenClaw as the agent framework. Let it handle Slack/Telegram/iMessage (via adapter if needed), bindings-per-group, sandbox-per-non-main agent.
• Previously ruled out, now reconsidered on merit.

Pros. Multi-channel adapters already exist (Telegram, Slack; iMessage via partner APIs). Binding model maps to per-chat-agent naturally. Skill ecosystem. 54 skills installed on HMA already. Cons. The prior-research files (openclaw-group-chat-security.md, openclaw-security-audit-2026-02-20.md) document real security issues — CVE-2026-25253 1-click RCE, ClawHavoc marketplace, supply-chain attacks. Tight version hygiene required. OpenClaw's binding policy has footguns (missing bindings silently fall through to unsandboxed main agent per Jacob's CLAUDE.md). Less control over Linq specifics. iMessage support is less-native than Slack/Telegram. Best for. Fastest path to a working Slack/Telegram bot with tool-use, if Jacob is willing to take on OpenClaw version hygiene. Probably NOT the right fit for iMessage primary since Linq integration isn't OpenClaw-native.

Option 6 — "Knowledge-drop-in: noos graph on a different machine"

Not an alternative — an orthogonal layer.

Any of options 1-5 can adopt this. noos's graph DB is queried over HTTP (x-api-key) by the agent at turn time, via an MCP server or a simple tool the agent can call. No migration of noos is required; picortex just becomes another noos consumer.

Questions that live here:

• Q5a: Which chats see which nodes? Per-chat API keys / scopes?
• Q5b: Write-back? Does the agent add nodes to the graph on Jacob's behalf, with per-chat attribution?
• Q5c: Is the graph queried every turn (expensive) or only on-demand (agent decides)?
• Q5d: Which lives where — noos on its own VPS, or bundled with picortex?

Hybrids worth naming

Option 2 + Option 6: Piyush-layout with noos graph as a separate machine's HTTP service. Most likely to be the v0.1 shape.

Option 4 + Option 6: Pure-texting MVP with noos graph for memory. Ship in days, upgrade to Option 2 if development-surface ends up needed.

Option 4 → Option 2 upgrade path: Ship Option 4 as v0.1. The moment we need a file browser or terminal, add a workspace host and migrate. All that changes is the agent invocation: transcript-based claude --print → SSH-based claude -p. Frontend picks up new routes.

Evaluation matrix (to be filled in while reviewing the Q* tickets)

Filled in as the Q tickets are worked.

Ordered brainstorm tickets

These are the questions to answer in order before committing to an option bundle. Each ticket links back to this doc.

See beads picortex-Q0 through picortex-Q8.

Open contention with current picortex docs

If Option 2, 3, or 4 wins, significant sections of the existing picortex specs change:

• spec/002-tmux-session-spawning.md — deleted or replaced (Options 2/3/4 all drop tmux)
• spec/003-web-terminal-xtermjs.md — deferred if Option 4, optional if Options 2/3
• spec/004-file-browser.md — deferred if Option 4, optional if Options 2/3
• spec/001-workspace-isolation-linux-users.md — kept for Options 2/3, dropped for Option 4
• ADR-0002 Linux-users-over-Docker — survives under Option 2, challenged by Option 3
• ADR-0003 tmux-for-session-persistence — superseded by any non-tmux option

Treat those as provisional until Q0-Q4 close.

References

• Piyush-era design study
• Codex review 2026-04-23 — pushed for claude --print spike
• ~/memory/research/openclaw-group-chat-security.md — Option 5 risk model
• cortex-inheritance.md — inheritance rules