Controlling a running Leo session from an external script?

[Luka Golibrodo]

Hello everybody! I need some advice. I am trying to solve the following problem: there is a running LEO session with an outline open. Can I connect to this session from outside LEO and send commands to do something without closing the outline? For example, to write a piece of information into a node's body, to find a node, or to move it? This would be a kind of collaborative editing, so collisions are possible when I am working with this outline manually and an external command is received. But would it be okay, for example, to stack those external commands and wait until idle time? Or is there a better way to do it?

--

With Best Regards,
Luka 

[Edward K. Ream]

On Sat, May 30, 2026 at 10:31 AM Luka Golibrodo <luka.go...@gmail.com> wrote:

Hello everybody! I need some advice. I am trying to solve the following problem: there is a running LEO session with an outline open. Can I connect to this session from outside LEO and send commands to do something without closing the outline? For example, to write a piece of information into a node's body, to find a node, or to move it? This would be a kind of collaborative editing, so collisions are possible when I am working with this outline manually and an external command is received. But would it be okay, for example, to stack those external commands and wait until idle time? Or is there a better way to do it?

Have you tried Leo's server?

Edward

[Luka Golibrodo]

Edward, thank you for your response! I've tried leoserver - it is working perfectly, still, it seems to run a separate instance of LEO in a headless mode (gui='nullGui') - and I can't find a way to attach it to a running LEO session (native QT GUI) to view the exact same live state of the same outline. I need remote access to an outline while it is opened locally in the regular LEO. Is it possible?

--

With Best Regards,
Luka 

сб, 30 мая 2026 г. в 19:05, Edward K. Ream <edre...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS2ZU8-WxrXMeOU4N59xSJ3z1_fCwrwtXKo%3DKMzQvWppiw%40mail.gmail.com.

[Edward K. Ream]

On Saturday, May 30, 2026 at 5:05:06 PM UTC-5 Luka wrote:

Edward, thank you for your response! I've tried leoserver - it is working perfectly, still, it seems to run a separate instance of LEO in a headless mode (gui='nullGui') - and I can't find a way to attach it to a running LEO session (native QT GUI) to view the exact same live state of the same outline. I need remote access to an outline while it is opened locally in the regular LEO. Is it possible?

Not that I know of. Does anyone have any ideas?

Edward

[Thomas Passin]

What if the startup code were changed so Leoserver could optionally open a Qt gui instance instead of a nullGui? That ought to do it.

[Luka Golibrodo]

I tried to modify the startup code so leoserver could open a Qt GUI instance instead of `nullGui`. I attempted to pass the 'qt' setting to it, which is finally passed to `leoBridge`, but the flow hits the `createGui(self)` method. It appears `leoBridge` currently asserts that only `nullGui` is supported:

if self.guiName == 'nullGui':
    ...
else:
    assert False, f"leoBridge.py: unsupported gui: {self.guiName}

Resulting in: AssertionError: leoBridge.py: unsupported gui: qt

I'm pursuing this because I believe external access to the Leo running GUI session could enable some very useful features:

• Sync with external services. Bidirectional synchronization of nodes with cloud services or databases with live state synced: if a node changes in Leo, it updates externally, and vice versa.
• AI & LLM integration. For example, implementing an MCP (Model Context Protocol) server for Leo. This would allow LLMs (agents) to interact with tools and query / manipulate outlines directly.

     
Why live interaction? Accessing a running session (with a GUI) provides a "live" view of the outline. This allows for manual intervention and immediate feedback in familiar environment, which is much better than relying on headless automation scripts for PIM tasks.

Does anyone know if leoserver/leoBridge is hardcoded to be headless?

I'm also considering an alternative approach based on Leo's existing mechanism for handling external file changes. Since Leo already detects modifications and processes them during idle time, perhaps a similar approach could work for external commands? Like a listener that would queue external requests and execute them during the GUI's idle cycles. This would naturally prevent collisions while the user is actively working. Does this seem like a viable path?

I would greatly appreciate any guidance on where to start and general approach selection. Or maybe it already exists and implemented? Thanks in advance for any advice!

вс, 31 мая 2026 г. в 17:43, Thomas Passin <tbp1...@gmail.com>:

--

You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/leo-editor/1913b3f9-e9cd-4672-bd3a-e465ac31e59en%40googlegroups.com.

[Edward K. Ream]

On Sun, May 31, 2026 at 11:53 AM Luka Golibrodo <luka.go...@gmail.com> wrote:

I tried to modify the startup code so leoserver could open a Qt GUI instance instead of `nullGui`. I attempted to pass the 'qt' setting to it, which is finally passed to `leoBridge`, but the flow hits the `createGui(self)` method. It appears `leoBridge` currently asserts that only `nullGui` is supported:

Well, that should be easy to fix. I'll do it today.

Edward

[Edward K. Ream]

>> On Sun, May 31, 2026 at 11:53 AM Luka Golibrodo wrote:

I tried to modify the startup code so leoserver could open a Qt GUI instance instead of `nullGui`. I attempted to pass the 'qt' setting to it, which is finally passed to `leoBridge`, but the flow hits the `createGui(self)` method. It appears `leoBridge` currently asserts that only `nullGui` is supported:

> Well, that should be easy to fix. I'll do it today.

PR #4720 allows the Qt gui. How does that work for you?

Edward

[Luka Golibrodo]

The issue appears more complex, as the code still initializes 'nullGui' on the subsequent line.

I attempted to invoke the Qt GUI explicitly using the following code:

elif self.guiName in ('qt'):

   g.app.createQtGui('', verbose=False)

The window appeared, but it was empty. I'll try to track this further...

вс, 31 мая 2026 г. в 21:19, Edward K. Ream <edre...@gmail.com>:

--

You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/leo-editor/c53f9cc6-0672-48f3-8f51-b8943c865650n%40googlegroups.com.

[Edward K. Ream]

On Sunday, May 31, 2026 at 1:45:40 PM UTC-5 Luka wrote:

The issue appears more complex, as the code still initializes 'nullGui' on the subsequent line.

I attempted to invoke the Qt GUI explicitly using the following code:

elif self.guiName in ('qt'):

   g.app.createQtGui('', verbose=False)

The window appeared, but it was empty. I'll try to track this further...

PR #4720 now works for me with the Qt gui. The first comment of the PR gives an example.

I still don't understand why you want to use the bridge this way, but that's a statement of my ignorance.

HTH.

Edward

[Luka Golibrodo]

Edward, thank you very much! Now I'll try my ideas with the Bridge.

For example, I want a local AI chatbot (like Open WebUI) to interact with my outline via voice input. When I say, 'Add a task to Project X with a due date...', the chatbot parses that input, plans the actions, and uses Bridge to access the running Leo, find the project tree, and add the task.

--
With Best Regards,
Luka 

пн, 1 июн. 2026 г., 02:02 Edward K. Ream <edre...@gmail.com>:

--

You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/leo-editor/5ce4dc94-b533-4c17-9cab-07545d442ce2n%40googlegroups.com.

[jkn]

I hope I am not hijacking this thread too much ... some version of this topic is of interest to me and I have what may be a similar use case...

I run leo on different machines in my local network. Typically these are all updating the same files (shared via Seafile, like a local dropbox etc.)

I try not to risk update clashes, and Leo's ability to reload if a change on disk is detected helps - but clashes do sometimes occur.

What I would like is a way, on machine B, to communicate with a running Leo on machine A, and say, for instance, "Save all changed files", or "exit now".

I plan on spending a bit of time learning more about Leo's server and bridge facilities shortly, but does this sound like the way to go? I am a little unclear whether I would have to have started the Leo on machine B using the server/bridge, or if Leo started 'bare' already has a mechanism to allow it to be communicated with. Perhaps this is where the discussion above is headed, I am just looking for a bit of clarification...

Thanks, J^n

[Edward K. Ream]

On Mon, Jun 1, 2026 at 2:28 PM jkn <jkn...@nicorp.co.uk> wrote:

I hope I am not hijacking this thread too much ... some version of this topic is of interest to me and I have what may be a similar use case...

No worries. This discussion won't affect Leo 6.8.9.

Edward

[Félix]

Hi y'all :) 

On the matter of multi-user connections and interactions to live leo documents opened & 'served' by a leobridge instance running in leoserver.py.

I'm a bit busy porting the finishing touches of Leo 6.8.9 to LeoJS, Leo-Web, &  LeoInteg to chime in more details on this fascinating subject - but here are just two quick thoughs in the meantime.

Simultaneous multiuser already has a working implementation as LeoInteg clients, but it would be pretty cool to have the 'original' python Leo UI connect and interact with the server indeed! :)

Having just read the above thread quickly, I'll just say for now I think having a leoclient.py use a Qt GUI  instead of leoserver (keeping leoserver started separately with a nullgui) may be a better avenue to turn to, but I'm not totally sure, that's just a first thought that came to mind... hehe..

I’ll take some time to think more thoroughly about this matter and will probably have some ‘demos’ and ‘suggestions’ for you in a few days!

Félix 

@edward : Ah! The interest in using the bridge this way is to somehow use Leo as an interactive multi-player game! :D (Or more seriously to edit in the manner of multi-user office programs where you see the live cursors and interaction of multiple users in an opened document in programs such as excel, etc. in real time) 

[Thomas Passin]

I could swear I remember years ago, when playing with leoserver I suppose, communicating with a running visible Leo window. All details are gone, sad to say.

[jkn]

I know I asked about this sort of thing myself, and probably got pointed to the leoserver, but didn't have time to follow up. I might be able to have a look again over the next couple of weeks.

In any case, I am glad this this general topic has come up again, and thank Félix for his interest ;-)

[jkn]

FWIW, I previously asked here: (not a lot of info there...)

    https://groups.google.com/g/leo-editor/c/7b-Rebw6Ajg/m/VVE41mE1BAAJ