Аз ин ҷо оғоз кунед
Connected Workspaces Guide
This guide explains how to connect a GitHub repository or Google Drive to Milly Lab, what happens to your files, and how proposed changes reach your real repository. It is for anyone using Swarm Mind with their own code or documents.
Read the section "What Milly Lab can see" before connecting anything. Connecting a workspace grants real access to real files.
#The one thing to know first
A run never writes to your repository or Drive. Every change a model proposes is held in a staging area attached to that session. Nothing reaches GitHub or Drive until you open the review panel and press Apply.
If you close the session, discard the changes, or simply never press Apply, your repository is untouched.
#What a connected workspace does
Once connected, a Swarm Mind run can:
- List the files and folders in the workspace.
- Read file contents and use them as context.
- Propose new files, edits to existing files, and deletions.
That last one is a proposal, not an action. See "Reviewing and applying changes" below.
#What Milly Lab can see
GitHub
Milly Lab requests the OAuth scope repo.
Understand what you are granting.
repois GitHub's scope for full read and write access to repository content. It is not scoped to the single repository you choose inside Milly Lab. The token GitHub issues is technically capable of reaching every repository your account can access — private repositories included, and repositories belonging to organisations you are a member of.Milly Lab confines itself to the repository selected for the session and rejects file paths that try to escape it. That confinement is enforced by Milly Lab's code, not by GitHub.
If that is broader than you are comfortable with, connect from a GitHub account that only has access to the repositories you intend to use.
Google Drive
Milly Lab requests the scope drive.file.
Google limits this scope for you: Milly Lab can only see files you specifically open with Milly Lab and files Milly Lab itself creates. The rest of your Drive is invisible to Milly Lab. This is a genuine technical boundary, not a policy promise.
Where your file contents go
Files that a run reads are sent to third-party AI model providers as context — the same providers that process your prompts, listed in the Subprocessor List.
Before you connect a repository, consider whether it contains:
- API keys, tokens, passwords or
.envfiles - Customer or employee personal data
- Material you are contractually forbidden to disclose to a third party
If it does, do not connect it. There is no way to retrieve content from a model provider once it has been sent.
#Connecting a workspace
You connect from the composer, at the start of a new Project Mode or Council Mode session. There is no separate settings page for this.
- Go to
/app/projector/app/council. - In the composer, open the file-source menu (the attachment control).
- Choose GitHub or Google Drive.
- A new browser window opens on the provider's own sign-in and consent screen. Approve there.
- The window closes by itself and returns you to the composer.
Your draft is preserved. Whatever you had typed, and any options you had set, are still there when the window closes. You do not have to start over.
If the popup does not appear, your browser has blocked it. Allow popups for Milly Lab and try again.
Choosing a repository
After GitHub is connected, Milly Lab lists the repositories your account can access. Pick one from the list — you do not type a repository name.
If you want the run to work in a new repository instead, leave the repository unselected and choose the new-repository option. Milly Lab creates the repository when you apply, not before — so abandoning the session leaves nothing behind on GitHub.
Choosing a Drive folder
You may select a folder to work in. If you do not, Milly Lab creates folders — and subfolders — as the task requires, when you apply.
#How a run reads your files
During the run, models list directories and read files as they need them. You will see this happen in the session's activity log.
Two caps apply, so a large repository does not stall the run or exhaust your budget:
| Limit | Value |
|---|---|
| Bytes read per file | ~48,000 (about 48 KB) |
| Entries returned per directory listing | 300 |
A file larger than the cap is truncated, not skipped. If a model seems to have missed something near the end of a large file, this is why. Point it at a smaller file, or split the file.
Reading files consumes your allowance, because file contents are sent to the model as input tokens. A run over a large repository costs more than the same run without one.
#Reviewing and applying changes
When a run proposes changes, they appear in the changes panel for that session. Each entry shows the file path, whether it is a create, edit or delete, and the proposed content.
Nothing in this panel has touched your workspace.
Applying
Press Apply and choose where the changes go:
| Target | What happens |
|---|---|
| Default branch | Commits directly to the repository's default branch |
| New branch | Creates a branch and commits there, leaving the default branch untouched |
| New repository | Creates the repository, then commits into it |
You can also set the commit message. If you leave the target blank, Milly Lab uses whatever the run proposed based on your original instructions — for example, if you asked it to "put this on a branch", it proposes a branch.
For Google Drive, applying writes the files into the selected folder, creating any folders and subfolders needed.
Recommendation: use a new branch for anything substantial. It gives you a normal pull-request review before the code reaches your default branch, and it is trivial to delete if the result is wrong.
What Apply protects you from
- Conflicts. Milly Lab records the version of each file when it was read. If someone else has committed to that file in the meantime, that file is reported as a conflict and left alone rather than overwritten. Other files in the same apply still go through. Re-run the task to pick up the newer version.
- Double-apply. A second Apply arriving while the first is still running is rejected. A double-click cannot produce two sets of commits.
- Applying mid-run. Apply is refused while the run is still going, because the run can still change what is staged. Wait for it to finish.
Discarding
Discard clears the staged changes. The session and its conversation stay; only the proposed file changes go. Your repository was never touched, so there is nothing to undo.
Partial failures
If some files fail to write — a permissions problem, a conflict, a path the provider rejects — the ones that succeeded stay applied and the panel reports which failed and why. Apply is not all-or-nothing.
#Disconnecting
Disconnect the workspace from the same file-source menu you used to connect it. This removes the connection and its stored token from Milly Lab.
Disconnecting in Milly Lab does not revoke the authorisation at the provider. To withdraw the grant completely, also do this:
- GitHub — Settings → Applications → Authorized OAuth Apps → Milly Lab → Revoke
- Google — myaccount.google.com/permissions → Milly Lab → Remove access
Do both if you want the access fully withdrawn.
Files already written to your repository or Drive by a previous Apply stay where they are. Disconnecting does not reverse them.
#Troubleshooting
"Repository not found" when the run starts The repository name did not resolve. Re-select it from the picker rather than relying on a name typed earlier. If it belongs to an organisation, confirm your GitHub account has access and that the organisation has not restricted third-party OAuth applications — many do. An organisation owner must approve Milly Lab under the organisation's third-party access policy.
The consent screen says access is blocked, or shows error 403 access_denied
The Google OAuth application is not yet verified for public use, so only accounts added as test
users can connect.
The popup closed but nothing connected The connection is bound to the browser window that started it. If the popup was opened in a different browser or profile than the one you are using Milly Lab in, the binding fails by design. Start the connection again from the same browser.
The run did not see a file I expected Check the file is inside the selected repository or the folder you chose. For Drive, remember Milly Lab can only see files you opened with Milly Lab or that Milly Lab created — a file sitting elsewhere in your Drive is invisible to it.
Apply reported a conflict Someone committed to that file after the run read it. Milly Lab refused to overwrite their work. Pull the latest changes, re-run the task, and apply again.
"An apply is already in progress" A previous Apply is still running. Wait — the claim releases automatically after two minutes even if something went wrong.
"Wait for the run to finish before applying changes" The run is still executing and can still modify what is staged. Let it finish.
The session's workspace connection is gone The connection was removed or expired between the run and the apply. Reconnect the workspace, then re-run the task — the staged changes cannot be applied through a different connection.