Auto-Claude's Future: Local-Only vs Remote Execution Support (include WSL2) ?

[theo-stocchetti]

Current Situation

Auto-Claude works great on macOS but faces challenges on Windows (#609, #458, #147):

• Python backend issues
• Process spawning failures
• Path handling differences

This raises an architectural question about the project's direction.

---

Two Paths Forward

Option A: Monolithic Desktop App (Current)

Keep: Tight coupling between Electron GUI and Python backend

✅ Simple one-click experience
✅ Everything local and private
❌ Windows issues require complex workarounds
❌ No remote execution or team collaboration

---

Option B: Client-Server Architecture

Change: Separate GUI from backend, communicate via WebSocket API

✅ Solves Windows issues (backend in WSL, native GUI)
✅ Enables remote execution and team collaboration
✅ Better resource utilization
❌ More complex architecture
❌ Requires migration effort

Note: "Simple mode" (one-click local) would remain the default experience.

---

@AndyMik90, How do you envision Auto-Claude's future?

• Should it remain a personal desktop tool focused on local execution?
• Or evolve into a platform that supports both local and remote workflows?

Maybe I'm not the only one, but I'd be curious to know how you see things on this subject.

Thank you,

[dataseeek]

Hello. I have recently started working on a hard fork using Option B: Client–Server Architecture, as I plan to run it on my own server with Ubuntu 24.04.3 LTS (Noble Numbat). My objective is to develop a web interface (frontend) alongside a backend API, enabling a clean separation between presentation and server-side logic.

What I've Built

I separated the React UI from the Python backend into a proper client-server architecture:
Browser (React + Vite) ←──WebSocket/REST──→ FastAPI Server ←──→ Python Agents

The key change: Instead of everything running inside Electron, the backend now runs as a standalone FastAPI server.
The frontend is just a React app that talks to it via HTTP and WebSocket.

How This Helps with Windows Issues

Windows Problem	Client-Server Solution
Python backend issues	Run backend on Linux/WSL, access from Windows browser
Process spawning failures	Terminal processes run on Linux server
Path handling differences	Server handles all paths; frontend is path-agnostic
node-pty issues	Backend uses ptyprocess on Linux instead

What's Working

• Kanban task board with drag-and-drop
• Real-time terminal in browser (xterm.js via WebSocket)
• Monaco code editor with file browsing
• Task execution with live progress
• GitHub/GitLab integration
• Multi-user support (multiple browsers can connect)
• Remote access from any device

Roadmap

What I'm working on next:

• Production build - Optimized frontend served by FastAPI (no separate dev server needed)
• Authentication improvements - Better auth system and users management
• Bug fixes & stability - Making current features more reliable

And Before I make this fork repo public , I wish to work on it a little bit more, to fix bugs and improvements so I dont get many PRs.
Just sharing my approach for those interested in this direction.

[BigFoxMedia]

Hello. I have recently started working on a hard fork using Option B: Client–Server Architecture, as I plan to run it on my own server with Ubuntu 24.04.3 LTS (Noble Numbat). My objective is to develop a web interface (frontend) alongside a backend API, enabling a clean separation between presentation and server-side logic.

What I've Built

I separated the React UI from the Python backend into a proper client-server architecture: Browser (React + Vite) ←──WebSocket/REST──→ FastAPI Server ←──→ Python Agents

The key change: Instead of everything running inside Electron, the backend now runs as a standalone FastAPI server. The frontend is just a React app that talks to it via HTTP and WebSocket.

How This Helps with Windows Issues

Windows Problem Client-Server Solution
Python backend issues Run backend on Linux/WSL, access from Windows browser
Process spawning failures Terminal processes run on Linux server
Path handling differences Server handles all paths; frontend is path-agnostic
node-pty issues Backend uses ptyprocess on Linux instead
What's Working

• Kanban task board with drag-and-drop
• Real-time terminal in browser (xterm.js via WebSocket)
• Monaco code editor with file browsing
• Task execution with live progress
• GitHub/GitLab integration
• Multi-user support (multiple browsers can connect)
• Remote access from any device

Roadmap

What I'm working on next:

• Production build - Optimized frontend served by FastAPI (no separate dev server needed)
• Authentication improvements - Better auth system and users management
• Bug fixes & stability - Making current features more reliable

And Before I make this fork repo public , I wish to work on it a little bit more, to fix bugs and improvements so I dont get many PRs. Just sharing my approach for those interested in this direction.

Looking forwards to you making this fork public! All my work is done on remote servers, nothing is local so as much as this project is golden, it's of no use to me, and I suspect many others, without a proper to install it as a web server on my remote servers.

[dataseeek]

@BigFoxMedia. Me and my team working on it, fixing bugs issues and some frontend sync. But it should work! Probably by next week I release a more fixed stable version.

[mdlmarkham]

@dataseeek - looking forward to it!

[tranlm]

Glad to see I wasn't the only one thinking of setting up remote execution support!

[colinmollenhour]

100% agree that Client/Server is the way to go! Honestly, as a SWE that does heavy Linux-centric development, a Windows app that doesn't have proper WSL (i.e. does not use the \wsl$ share) or Client/Server architecture is basically unusable in my opinion. Not only for WSL but imagine being able to run Auto-Claude server 24/7 remotely, then access it from your laptop or mobile device through a remote UI! This is really the only thing that made OpenClaw such a hit is that you can run it remotely, so Auto Claude with client/server model would directly compete with OpenClaw among scads of other tools.

[VDT-91]

oh, its coming <3