Since Sculptor allows you to use custom docker containers (devcontainers), you can check out the other projects in there.
Then your primary project (from Sculptor's perspective) is simply whatever contains the devcontainer / dockerfile that you want it to use (to pull in all of those repos)
It's still a little awkward though -- if you do this, be sure to set a custom system prompt explaining this setup to the underlying coding agent!
It actually originally worked that way, and you can still mostly kinda use it that way (except that, because of CSRF protection, it's obnoxious -- run the program once to figure out the command line that the backend python process is started with, eg, via `ps -Fe` on linux, then shut down the app, then run that process. As long as you don't set the `ELECTRON_APP_SECRET` env var, CSRF will be disabled. Use `netstat -pant | grep -i listen` to figure out what port it is listening on)
Obviously not the most user friendly or usable, but we found that people often got pretty confused when this was a browser tab instead of a standalone app (it's easy to lose the tab, etc)
sculptor_backend seems to consume a lot of CPU and memory when just idling. Would you consider switching from Electron to Tauri so it uses the native WebView of the OS?
I haven't tried it, but it might work if you set the env var yourself (I think you can create a `.env` file in `~/.sculptor/.env` and it will be injected into the environment for the agent)
I'd give it a good 20% chance of working if you set the right environment variables in there :) Feel free to experiment in the "Terminal" tab as well, you can call claude directly from there to confirm if it works.
Nope, not based on vibekit, but it looks like a cool project!
Our approach is a bit more custom and deeply integrated with the coding agents (ex: we understand when the turn has finished and can snapshot the docker container, allowing rollbacks, etc)
We do also have a terminal though, so if you really wanted, I suppose you could run any text-based agent in there (although I've never tried that). Maybe we'll add better support for that as a feature someday :)
Then claude runs in a container created from our default image, and any code it executes will run in that container as well.
> Can Claude Code execute tests by itself in the context of the container when not paired?
Yup! It can do whatever you tell it. The "pairing" is purely optional -- it's just there in case you want to directly edit the agent's code from your IDE.
> Do they all share the same database?
We support custom docker containers, so you should be able to configure it however you want (eg, to have separate databases, or to share a database, depending on what you want)
> Running full containerized applications with many versions of Postgres at the same time sounds very heavy for a dev laptop
Yeah -- it's not quite as bad if you run a single containerized Postgres and they each connect to a different database within that instance, but it's still a good point.
One of the features on our roadmap (that I'm very excited about) is the ability to use fully remote containers (which definitely gets rid of this "heaviness", though it can get a bit expensive if you're not careful)
> the feature I was most looking forward to is a mobile integration to check the agent status while away from keyboard, from my phone.
Since our launch 2 years ago, we've focused more on the "agents that code" part of our vision (so that everyone can make software) rather than the "training models from scratch" part (because there were so many good open source models released since then)
This is from our fundraising post 2 years ago:
> Our goal remains the same: to build practical AI agents that can accomplish larger goals and safely work for us in the real world. To do this, we train foundation models optimized for reasoning. Today, we apply our models to develop agents that we can find useful internally, starting with agents that code. Ultimately, we hope to release systems that enable anyone to build robust, custom AI agents that put the productive power of AI at everyone’s fingertips.
Then your primary project (from Sculptor's perspective) is simply whatever contains the devcontainer / dockerfile that you want it to use (to pull in all of those repos)
It's still a little awkward though -- if you do this, be sure to set a custom system prompt explaining this setup to the underlying coding agent!
(I'm a founder of Imbue, the company behind Sculptor: https://imbue.com/sculptor/ )