Long overdue - I was all in a few years ago with Warp, but after the last couple of years of not addressing this need, I have moved on from Warp. I now DO NOT see the need to embed AI into the terminal when you can have all sorts of TUI doing the same job.

What about when SSHing to an external server, or working in a container?

Nanobot will happily ssh to a host and do things on it. I'm sure that's just a skill away for pi or opencode.

Confirming that Pi can definitely handles this. I've written a harness "factotum" based on pi just for managing my homelab and my radio club's systems. Has absolutely no issue sshing into things remotely, running ansible/helm/kubectl/talosctl commands.

There's a few skills, a and an extension to switch inventory. The extension is only needed because I want to switch between the two organizations. It's pretty slick. One of my use cases was just getting my homelab under control. So one of the first tasks I gave it was to go find everything that's running on these hosts, system services, docker compose, kube pods, etc. Builds an inventory, memory, todos.

Switches the script from "ai helps me launch more experiments to lose track of" to "organized and back under config management".

  .pi/factotum/
  ├── active-profile
  ├── profiles
  │   ├── club
  │   │   ├── config.yaml
  │   │   ├── inventory
  │   │   │   └── hosts.yaml
  │   │   └── todos
  │   │       ├── 22a094a3.md
  │   │       ├── 427ad844.md
  │   │       ├── 4c185be7.md
  │   │       ├── 4d0eea0f.md
  │   │       └── bcf069a4.md
  │   ├── examples
  │   │   ├── config.yaml
  │   │   └── inventory
  │   │       └── hosts.yaml
  │   └── local
  │       ├── config.yaml
  │       ├── inventory
  │       │   └── hosts.yaml
  │       ├── memories
  │       │   ├── axel-services.md
  │       │   ├── fran-mydiffuser.md
  │       │   ├── fran-services.md
  │       │   ├── ruffclus-cluster.md
  │       │   └── ruffclus-paperless-ngx.md
  │       └── todos
  │           ├── 0f7fd63e.md
  │           ├── 75c82ceb.md
  │           ├── 9cb63594.md
  │           ├── af33e08f.md
  │           ├── ba490542.md
  │           ├── c09c144f.md
  │           ├── c5f7f8a8.md
  │           └── d4c4b287.md
  ├── schemas
  │   ├── PROJECT_ARCHITECTURE.md
  │   └── project-architecture.yaml
  ├── task-templates
  │   └── host-audit.yaml
  └── tools
      └── host_audit_runner.sh

How do you use `pi` to ssh? I use `oh-my-pi`, and tried the `/ssh` command, but I couldn't get it to work. Then I saw a suggestion somewhere to just run `!ssh` to place things into the agent's context.

Is there a way to use it like "The current directory is at `ssh server`" and have the agent work from there?

so, to be clear, is it just doing random bash commands to runn ssh or is it a actual tool, eg, node-ssh command interface.

i would not trust bash execution of SSH because it can easily hallucinate local commands instead of remote.

Background: I use OpenCode to do this.

Just tell it to use ssh from the shell. From there you can give it extra context to describe the target (if you know/care about it), or just let it loose and if the environment doesn't have what it expects it will "figure something out" - just the same as with your local env.

If there's some least common denominator you know about e.g. python it can streamline things if you tell it to just use that for everything.

I don't think you understand. I'm well aware it can run whatever command on bash. You're taking a significant risk asking it to do what it's doing via ssh, because it could easily forget that it's suppose to be doing ssh and do whatever locally.

The point is: opencode should have a specific deterministic tool like https://www.npmjs.com/package/node-ssh where commands can only be run; the environment can only be the remote; etc.

The last thing I would want is for it to suddenly forget it's suppose to be running commands as ssh and does something local.

In practice I just don't think this is a real problem, or at least not one I've seen.

I do something like this a lot with local VMs managed through Incus (so not literally invoking ssh but the exact same pattern) and they don't "mess up" in that particular way. If they ever did they figured it out immediately and I didn't even make note of it happening.

I guess to sum up my feelings on it: if you don't think the tool is reliable enough to correctly use ssh to execute remote commands, you probably shouldn't be trusting it to run remote commands in the first place.

You're still ignoring the crux of the difference in _risk_. Say the risk of `rm -rf /` for any given model is 1%. That is, the probabilty, that it'll just absolutely saveagly destroy the system you're working on. We know it's lower than that, because millions of tokens per day are generated and we only get a few of these "production database was wiped" news items.

There difference is still: If that risk-reward is to be recieved, you can't tell me you'd rather have it run locally than on some system you're managing. Because POV, you're the one responsible and if a coding tool _takes out your system_, you no longer have any means to fix the problem.

So, maybe the risk-reward is _technically_ equal, but only if the operator of the coding tool continues to operate regardless of what commands it's issuing. That's not the case if you're just saying "hey guy, use ssh for all your commands"

> i would not trust bash execution of SSH because it can easily hallucinate local commands instead of remote.

Why would it be more likely to hallucinate local commands instead of remote commands if it is in an active SSH session?

I think you're reading into the statement.

It can equally hallucinate commands. Fine. The problem is, if I'm working on a remote machine, I'm generally doing things that I'd be less concerned about. If I'm on a VPN and it rm -rf / while I'm trying to clean it up; bad break, but it's not _my machine_ it just removed root on.

So if your LLM is just running something like `ssh <remote> "<cmd>"` it could easily foget the ssh <remote> part and suddenly you're modifying your local system.

So it's one thing to YOLO on production servers, etc, but wiping out something locally is a significantly different event. Imagine it erasing all your scripts or whatever.

Anyway, the point is: I wouldn't trust an agent operating with just a bash cli running ssh commands.

Most if not every agent has access to bash or similar, which ssh typically is available. You don't need any bloated skills or anything, as long as you include `host is available via [email protected]` or whatever, and you have authentication properly setup, it'll figure it out.

This might have changed but Warp was not able to do this without “warpifying” the SSH host.

I mean… Claude Code desktop will SSH into anything and start coding for ya. Which could sound horrifying but if you setup an isolated system for that specifically its not that horrifying.

Hand your agent a tmux session.

I wrote a little wrapper to start tmux with two panes open, one pane is an ssh connection to a host and one runs Claude Code, with an auto-generated CLAUDE.md telling Claude to use tmux commands to interact with the remote host (https://github.com/swelljoe/tandem). Agents can also use ssh, but I wanted an interactive way to poke around on a remote system and also be able to ask Claude to look at or do something on its own without copy/paste.

I was looking at warp, wave, and a few others, and this is the exact stuff I will need, thanks for sharing.

So when I SSH to remote servers, I would like to bring my agent buddy with me, currently, I open two terminals, one with a remote SSH session, and one with opencode/claude code, now I have to copy & paste commands/info between the 2 terminals, which can be anoyying, so that is why I was looking at warp, but it has a paywall for BYOK :)

Looks like there is a "neuter" fork out there: https://github.com/GarethCott/warp#whats-different-from-upst...

Makes plenty of sense to upstream this (possibly makes more more than forking, although I suppose it's one way of gauging interest and implementation complexity).

Let me tell you a disturbing fact. The open source warp does not even have prompts. It is completely cloud-based, including the calling process of various tools in oz cloud. So I think it is better to change than to wait.

Will this require a paid plan? That is, could Warp, when modified, work with a local model on Ollama, no charge?

what is the point of an "ai-terminal" when you can already just directly run ai in a normal terminal

your banner says:

> Bring any AI model into your terminal

its already there. there is no need for a special terminal to do this. in fact better to not have such a thing

Despite the newish "AI" branding for what I would presume is marketing buzz reasons, most of Warp is really centered around trying to make a terminal interface not anchored to legacy assumptions, like the blocks functionality (https://docs.warp.dev/terminal/blocks).

This page doesn't tell me anything useful about what this feature does or how it works. The attached screenshot is pointless. I assume the actual information is in the embedded Youtube video. YouTube is not an acceptable alternative to written documentation

That was exactly my question; why fork? I assumed the project owners were preserving their business model, but if you allow it to be opened-up and turn off the cloud features, I see no reason to fork.

Cool will run this in Hyperia.