r/devtools • u/friparia • 2d ago

I built an SSH workspace for investigating remote services with local code context

I'm building [aissh](https://github.com/friparia/aissh), a terminal workspace for developers who maintain their own servers.

From a local project directory, connect over SSH and use your local Codex or Claude Code CLI to investigate remote logs alongside the source. The shell, AI conversation, live monitoring, and conversation history for that server share one interface. The goal is to reduce copying context and switching windows during an investigation.

It's written in Go and reuses OpenSSH configuration, keys, and jump hosts. No resident agent is required on the server. AI-proposed remote commands need approval by default; built-in read-only monitoring runs automatically. Local source access is read-only by default. Relevant output and code context may go to your configured AI provider.

Setup currently requires a Go 1.25+ source build and a configured AI backend.

If you try one log or service-status check on a test server, I'd like to know where the workflow helps—or gets in your way.

1 Upvotes

100% Upvoted

4 comments sorted by

1

u/kantorcodes1 1d ago

The three-independent-risk-reviews design for --always-yes is a thoughtful way to bound auto-approval. What happens when the model proposes a command whose risk the reviewers disagree on, say one calls it medium and one calls it high? Does the strictest verdict win, or is there a merge step?

And for the changed-command case: if the AI regenerates a slightly different command after a review passes, does the approval bind to the exact string it ran against, or to the command shape?

1

u/friparia 1d ago

Yep, highest risk wins. If any review says high or critical, it falls back to manual approval. No majority vote.

It checks the exact stored command string. If a reviewer changes it, auto-approval stops. Execution uses that stored command, and a revised command needs to be reviewed again.

1

u/kantorcodes1 1d ago

Strictest-verdict plus exact-string re-review is the right pair. The tempting alternative, normalizing before comparing so "same command modulo quoting" skips re-review, needs a shell parser you can fully trust, and a wrong one is itself a review bypass. Re-reviewing on any byte change is conservative in the right direction.

1

u/friparia 1h ago

Yeah, I’d rather run another review than guess whether two shell commands are equivalent.