Support for remote agents

[christopherflora]

Summary

Agents accessed via SSH cannot view the local file links.

Motivation

I keep my agents in a sandboxed container to minimize security concerns with my local filesystem. So in the plugin, I set up a custom agent with the command ssh and the arguments providing the host and other information needed (using hermes-agent as a backend).

This works great for chat, and it works great for notes that I explicitly link with the @Note syntax, but does not work for the current note. The current note is instead sent as a file link on my local computer which my remote agent cannot read.

Proposed solution

Have the current note sent the same way that the @-linked notes are sent. Or, create a setting that dictates whether files are sent by link or not (this could even be inferred from the way the agent is setup).

Alternatives considered

Currently, I am unable to use the automatic-current-note inclusion, so have to disable it. But it would be super useful if this feature were added so that I could use it!

Additional context

No response

[athewsey]

+1 I was also looking into this option for Obsidian on mobile, where deploying the agent remotely would give some more flexibility than having to get it on to the device. I think ACP supports a remote http+websockets transport, right? It'd be cool to support it 🙏

[RAIT-09]

Hi @christopherflora, thanks for the thorough write-up — this is very doable. Here's the approach I have in mind:

A setting to send the opened note's content inline, for agents that can't read your local filesystem (remote/SSH/sandboxed setups like yours). With it off, the opened note stays a lightweight path reference as it is today; with it on, the content is embedded.

When it's on, the opened note is sent as content, the same way an @-mention is. To keep that efficient, instead of re-sending the whole note every message, the plugin embeds it the first time a note is referenced and whenever it changes (tracked via its modified time), sending just a small reference in between — the agent already retains the earlier content in its conversation history. And to stay robust even if the agent compacts its context, it re-embeds periodically.

That gives you the automatic current-note behavior you're after, working over SSH, without inflating token usage on every turn.

Does this approach work for you?

[RAIT-09]

Hi @athewsey, thanks — this is a great direction.

That said, it's a little different from what @christopherflora is asking for in this issue. Their case is sending the opened-note context to an agent that's already connected (over SSH) — i.e., a per-turn context behavior. What you're describing is the connection/transport layer itself — connecting over a native remote transport (e.g. websockets) instead of spawning the agent as a local child process, which is especially important on mobile where a local process isn't practical.

Since that's a separate (and larger) piece of work, I think it's best tracked as its own issue so it can get the proper focus — would you mind opening one? I'll dig into it in detail there.

[christopherflora]

That gives you the automatic current-note behavior you're after, working over SSH, without inflating token usage on every turn.
Does this approach work for you?

This sounds perfect - a simple config switch, no need to overcomplicate (like trying to automatically infer the setting based on the actual acp command).

My only other recommendation would be to update the documentation to help support this - maybe under the "custom agents" part, you could add a "remote" or "SSH" option that explains how to use SSH to connect to a remote ACP server, and mention on that page that this new setting is critical for the remote workflow.