It might be nice if Connect could tap in the desktop entry environment so that a file opened from a GUI just opens in a specified client – for instance, the client from where connect was executed.
So we could do something like:
connect nautilus
And all files would just open from Nautilus in the client.
I have to explore whether it’s possible when I have a bit of time (and the motivation 
) for it.
Though this would be cool, but I don’t use GUI file managers at all.What I think could be done is a shell script that is integrated to right mouse click menu edit with Kakoune that will either launch a new instance of Kakoune in a preferred terminal, or find an active client and open file in it. I don’t know how it should handle if there are more than one client active, perhaps choosing the most recent one.
But I thinks that this problem could be solved more easily by having Kakoune running as a daemon in the background always, much like Emacs daemon mode. A quote from the linked page:
Various programs can invoke your choice of editor to edit a particular piece of text. For instance, version control programs invoke an editor to enter version control logs (see Version Control), and the Unix mail utility invokes an editor to enter a message to send. By convention, your choice of editor is specified by the environment variable EDITOR. If you set EDITOR to ‘emacs’, Emacs would be invoked, but in an inconvenient way—by starting a new Emacs process. This is inconvenient because the new Emacs process doesn’t share buffers, a command history, or other kinds of information with any existing Emacs process.
You can solve this problem by setting up Emacs as an edit server, so that it “listens” for external edit requests and acts accordingly.
Perhaps the very same method could be utilized by Kakoune?