summaryrefslogtreecommitdiffhomepage
path: root/notes/ssh-support-plan.md
AgeCommit message (Collapse)Author
4 daysplan(ssh): lock final decision — take ssh-config dep; no open questions remainAdam Malczewski
Resolve the last open question: take the ssh-config npm package (project-local, alongside ssh2) for correct ~/.ssh/config parsing rather than hand-rolling. §13 now lists all 8 decisions as resolved and marks the plan decision-complete. Also records minor adopted defaults (config reader lives in ssh extension; stale alias surfaced as unresolved not silent-local; default identity probing order; assume unencrypted keys for MVP). Planning document only; no code changed. No merge or push.
4 daysplan(ssh): bake in resolved decisions + ~/.ssh/config discoveryAdam Malczewski
Update the SSH support plan to reflect user-confirmed decisions and a key simplification from a new requirement: - New §0.5 'Resolved decisions' records all 7 confirmed answers. - Computer is now a READ-ONLY view over ~/.ssh/config (Host aliases), not a persisted CRUD entity: no computer-store package, no create/update/delete API. computerId IS an SSH config alias. ~/.ssh/known_hosts is the host-key trust store (auto-trust-and-pin). - Auth simplified to key-only from ~/.ssh (no gopass/SecretsAccess/secretRef anywhere). - ssh2 only (no bun-ssh2 fork); verifying under Bun is the load-bearing Phase-3 first step. - LSP/MCP silently dropped on remote turns (no system-prompt note); edit_file works with no diagnostics on remote. - computerId persisted per-conversation (like cwd). - Updated data model (§3), connection mgmt (§4), security (§7), edge cases (§8), API surface (§9 read-only), frontend (§10), packages table (§11, no computer-store), phases (§12), and resolved open questions (§13). Planning document only; no code changed. No merge or push.
4 daysplan(ssh): add transparent SSH support design & implementation planAdam Malczewski
Research and plan transparent SSH execution so an agent runs commands on a remote computer as if local — the agent never learns it is using SSH. Covers: - How the cwd → ToolExecuteContext pipeline works today and where a computerId threads in (mirroring cwd end-to-end) - The ExecBackend abstraction (spawn + fs) behind which tool-shell/ read-file/write-file/edit-file are refactored, with LocalExecBackend (node) and SshExecBackend (ssh2) implementations - Computer data model + workspace defaultComputerId + per-conversation override, mirroring the getEffectiveCwd resolution ladder (null = local) - SSH connection pooling (one per computer, lazy connect, keep-alive, idle reaping), auth via SecretsAccess/gopass, host-key verification - Turn loop / dispatch integration (additive optional computerId field, backward-compatible — absent = today's local behavior) - LSP/MCP degrade by dropping those tools on remote turns (future: remote server spawn over SSH) - API surface (computer CRUD, per-conv + workspace-default endpoints, chat.send gains computerId), frontend impact - Security, edge cases, phased implementation, contract gaps reported to unit owners (one-owner-per-unit honored — planner does not edit others) No code changed; planning document only. No merge or push.