Sounds great. I will try it!
1 Like
Thanks for the answer, I will try it also when I have a little time to change the setup. One question: Are sessions automatically created and managed by the MCP? I think that’s the most interesting feature about julia-mcp, as it makes the AI agent autonomously deal with the Julia sessions.
Is there a way to see what the agent does in the connected REPL session? When I tried it, the agent would send a command to the REPL and then wait a very long time, but I did not see what was taking so long. I would have expected at most a few second turn-around time for what I asked it to do.
Yes, you can see it in the Kaimon TUI under the activity tab. Whether the REPL mirrors output is a configuration setting, if you go to the config tab and type ‘m’ it will turn that on and off. Should probably be a project specific setting at some point but it’s global for now.
Currently the user is expected to launch a Julia session, generally inside of a project in order to establish the connection. I’ve been on the fence about whether to allow the agent to start sessions on its own, because it limits what the user might see inside the repl (although that’s not a fundamental issue as output is returned from the REPL and shown in the activity tab), but also limits interactivity with the session.
But the workflow is pretty simple (after a short one time setup to configure the MCP setting for your agent, etc.):
- Have Kaimon running via the script at
bin/kaimon. This runs the TUI. - Have your agent running and able to see the Kaimon MCP server (config step as mentioned above)
- Start a Julia session. This can be anywhere but I generally start one in whatever project(s) I’m working on with
julia --project. I have the global setup in my startup file (similar to Revise for example) so any interactive session I start will automatically connect with the Kaimon server.
That’s basically it, you can have multiple agents, multiple Julia sessions, multiple projects. If you want visibility into what tools are being executed, more detailed output (different agents show varying level of detail by default), it is all there in the TUI.
I’ve included some screenshots to illustrate what I mean. Let me know if that’s helpful or if you have more questions.
2 Likes
If the ability to have the agent start sessions on its own is important, it can certainly be supported. The main issue there is I guess controlling or configuring how the agent starts the sessions, and perhaps some configuration/permissions/discovery questions around how the agent knows about some project context and how it would use a tool to launch the session, some lifecycle management, etc.
With the current scheme, you create the session(s) where you want, the agent uses them. The agent is able to restart them when it needs to as well, with little downtime. For when Revise can’t load the new code, etc. There is a manage_repl tool with a restart option and it will quickly restart a fresh Julia session and tell the agent it’s in a fresh state with none of the previous variables, etc. present.
julia_mcp uses stdio for communication, so it is easy to block all network access to the sessions by using bubblewrap on Linux. How would I do the same with Kaimon.jl? Could you add an example of how to add sandboxing like GitHub - nhz2/SandboxMCPRepl.jl: A Julia repl session manager for AI using Sandbox.jl · GitHub does?
Kaimon uses a specified network port (2828 by default) over HTTP for agent ↔ Kaimon communication, according to the MCP spec’s Streamable HTTP transport. (Transports - Model Context Protocol)
I don’t currently implement stdio, but it could be done. Having the ability to do this across network boundaries has been more of an important use case for me.
The communication between Kaimon and Julia session is over ZMQ, using socket files, though TCP I also an option there (not currently implemented).
I haven’t used the setup you describe so it might take a little experimentation. If you find something that you would like to be supported, you could get in touch or file a GitHub issue (or a PR of course) 
.
Yes I think a stdio mode would very useful, as I don’t currently know enough about networking on Linux to trust myself to correctly manage that.
There’s not much to do in the standard setup, you can choose to use a standard HTTP authentication mechanism (OAuth Bearer token) for the MCP connection. This is auto configured for you for several common agent tools (Claude, Codex, etc.). The access between Kaimon and the Julia sessions just uses standard OS file permissions.
Looks awesome! I got it started in Antigravity (in Ubuntu devcontainer) but connection dropped and TUI crashed after a few minutes, without an obvious cause that I could report. Hoping to find an easy way to set up a local box where the agent has maximal freedom and tools.
@eteppo, thanks for looking. Is this reproducible, or just happened once? I’ve been fixing a few issues I’ve seen in the ZMQ messaging system, as well as some fixed in Tachikoma.jl the TUI framework. If you do get a segfault and can provide the stack frames/other detailed info, please do, you could file a bug in GitHub.
But I’ll be pushing a new release today which incorporates some recent bug fixes and enhancements, would you try again?
1 Like
Now it appears to run smoothly, not sure what happened. The only issue I had was that my MacBook started to heat up too much, maybe I am doing one or many not-so-clever things, but appears to be the TUI. Is it possible to leave Kaimon.start!() running or something to have the connection without the user interface for now?
It would be very helpful (even necessary) if we could launch the MCP server as a docker container.
See: https://www.docker.com/blog/build-to-prod-mcp-servers-with-docker/
Would it be possible to support that with Kaimon?
1 Like
What terminal are you using? Did you see the Julia process for Kaimon using a lot of CPU or memory? If you have details let me know. I run it and it’s stable for hours at least. If you can qualify what was going on please file a GitHub issue.
You could start Julia with startup-file=no (to prevent the interactive session from wanting to connect to Kaimon – although it wouldn’t really hurt, just maybe be confusing), then something like this:
# Headless Kaimon (pre-release workaround)
using Kaimon
Kaimon.start!()
mgr = Kaimon.ConnectionManager()
Kaimon.start!(mgr) # starts the connection manager scan loop
Kaimon.register_sessions_changed_callback!(mgr)
Kaimon.GATE_MODE[] = true
Kaimon.GATE_CONN_MGR[] = mgr
I’ll add a dedicated function which does this in the next release, coming soon.
The main issue is that currently the Julia session ↔ Kaimon connection is via ZMQ socket files, which I’d imagine would not work over the docker filesystem mounting. I haven’t checked though.
ZMQ also supports TCP connections, which would be my first instinct on how to work around this. I’m curious about the reasons it would be so helpful/necessary, what are the use cases you’re thinking about?
I think there are many. But some I would consider important:
- Easier parallelization, because each agent(s) can work in a separate file system without risk of collisions. Agents could fire up more containers as they need to.
- Security, isolation. I can sandbox the agent and decide what it has access to. Both in terms of software/tools, but also files.
- Persistence, reproducibility. Fix julia/package versions, continue where you left off.
1 Like
This works really well. Speeds up Claude code quite a lot. A couple of things I noticed is that claude code seems to start up it’s own server which is kind of a shame because the TUI is so nice but I’m not complaining. And claude seems to need to be explicitly told to use the Kaimon. Would a Julia skill fix this?
Some instruction in CLAUDE.md could help. I think claude should also start it’s own REPL gate, instead of fiddling with the startup file.
1 Like
This should not be necessary. I start Kaimon on its own and Claude is able to find it easily and I’ve never seen it try to start up a new instance.
Putting a mention about Kaimon/MCP in the CLAUDE.md has been effective for me. I also start new agent session with Please take the kaimon usage quiz.
I’ve been experimenting with the ability for the agent to independently start sessions and there is a HUGE update coming in the next couple days, stay tuned.
PS - For the courageous, I will push a preview of 1.1 to GitHub shortly. It requires also Tachikoma.jl 1.1 which will also be on a branch, so you might need to do some package fiddling to get it working but it’s not too bad.
3 Likes