Feature
Connected workspaces: the models propose, you apply
A connected workspace lets Milly Lab's Swarm Mind read a GitHub repository, Google Drive, OneDrive or a PostgreSQL database during a Council or Project session. Every file the models write and every SQL script they stage waits in a review panel; nothing reaches the real workspace until you press Apply, and you can discard it instead.
Last updated:
What can the models do in a connected workspace?
The models can list, read and search files freely; when they write a file or suggest a commit, the change goes to a staging area attached to the session, not to your workspace.
| Action | What it does | Effect on your workspace |
|---|---|---|
| List files | Lists files and folders, up to 300 entries per call | None: read only |
| Read a file | Returns a file's content, including the run's own staged edits; about 48 KB at most, the rest of a longer file is cut off | None: read only |
| Search files | Finds files whose path or name matches a query | None: read only |
| Write a file | Creates a file or replaces its whole content | Staged until you press Apply |
| Propose a commit | Suggests a commit message and a target, the default branch or a new branch, taken from your instructions | Staged until you press Apply |
| Query a database | PostgreSQL only: lists tables, describes columns, samples rows and runs one read-only SELECT at a time, returning up to 200 rows | None: read only |
| Stage SQL | PostgreSQL only: saves a SQL script for your review | Runs only when you press Apply |
What happens when I press Apply?
Apply writes the staged changes into the real workspace in one step that you start: on GitHub to the default branch, a new branch or a new repository; on Google Drive or OneDrive into the chosen folder; on PostgreSQL by running every staged script in one transaction.
| Destination | What Apply does |
|---|---|
| GitHub: default branch | Commits the files to the repository's default branch |
| GitHub: new branch | Creates a branch and commits there, leaving the default branch untouched |
| GitHub: new repository | Creates the repository when you apply, then commits into it; an abandoned session leaves nothing on GitHub |
| Google Drive or OneDrive | Writes the files into the folder chosen for the session |
| PostgreSQL | Runs every staged script in one transaction |
You can change the commit message and target before applying; if you leave them, Milly Lab uses what the run proposed from your instructions. Discard clears the staged changes and keeps the session; your workspace was never touched, so there is nothing to undo.
What does Apply protect against?
Apply refuses or isolates the risky cases instead of overwriting: a file changed on GitHub since the run read it is skipped as a conflict, a second Apply is rejected, and nothing can be applied while the run is still working.
- Conflicts: Milly Lab records the version of each GitHub file when the run reads it. If someone has committed to that file since, the file is reported as a conflict and left alone, while the other files still go through.
- Double Apply: only one Apply runs per session at a time, so a double click cannot create two sets of commits. If an Apply fails midway, the lock releases itself after 2 minutes.
- Unfinished runs: Apply and Discard are refused while the run is still working, because it can still change what is staged.
- Partial failures: files that were written stay written, and only the failed ones remain staged for another try.
- Database scripts: DROP DATABASE, role and privilege changes, COPY, DO blocks and transaction control are refused when a script is staged.
What are the limits?
One read returns up to about 48 KB of a file, one listing up to 300 entries, one staged file can be up to 256 KB, and a session can stage up to 2 MB of changes in total.
| Limit | Value |
|---|---|
| Content returned per file read | About 48 KB |
| Entries per directory listing | 300 |
| Size of one staged file | 256 KB |
| All staged changes in one session | 2 MB |
| Tool steps in one model turn | 12 |
| Rows returned by one database query | 200 |
What can Milly Lab access in my accounts?
GitHub is connected with the repo scope, which GitHub does not limit to one repository; Google Drive uses the drive.file scope, which shows Milly Lab only the files you open with it or that it creates.
- GitHub: Milly Lab works only in the repository chosen for the session and rejects file paths that try to leave it. That limit is enforced by Milly Lab's code, not by GitHub, so if the repo scope is broader than you want, connect a GitHub account that can reach only the repositories you plan to use.
- Google Drive: the drive.file limit is enforced by Google, so the rest of your Drive stays invisible to Milly Lab.
- Access tokens are checked with the provider when you connect, stored encrypted and never shown again.
- Files a run reads are sent to the AI model providers as context. Do not connect repositories that hold passwords, API keys or personal data you may not share.
- Disconnecting a workspace in Milly Lab deletes the stored connection, but the grant at GitHub or Google stays until you revoke it there.
Do chats and agents follow the same rule?
Chats and agents use connected accounts under a Writes setting for each account: Allowed, Ask before writes or Off. The default is Ask before writes, which shows an approval card with a preview before anything changes.
- Reads are always allowed; Off refuses writes and keeps reads.
- Actions that move money or stock always ask, even under Allowed, and never run unattended on a schedule.
- GitHub and Google Drive can also be connected as accounts for chats: reading repositories and files runs freely, while opening issues, commenting or uploading files asks first.
Which plans include connected workspaces?
Connected workspaces are part of Swarm Mind, which is included in the Max ($42/month), Advanced ($72/month) and Enterprise plans.