When two changes overlap
On a project shared by several people, or open on several of your devices. No setting to turn on.
Two people change the same lines of the same file: this is called a conflict. In VibeStarter, you don’t have to resolve it by hand. An AI agent takes care of it on the computer that gathers the team’s work, and the others never see anything.
The same conflict can happen without a team, between two devices on your account that changed the same file. That is why the messages talk about a “Version conflict.”
How a conflict unfolds
Section titled “How a conflict unfolds”Why you never see a conflict
Section titled “Why you never see a conflict”Each person saves on their own work line. These lines cannot contradict each other: the overlap only happens at the moment someone brings them together.
This bringing-together is done by one computer at a time: that of the first member connected, owner or editor. It keeps the role while it is connected, even with nothing to bring together. Another takes over if it disconnects, if it leaves work waiting without moving forward for 30 minutes, or if it cannot bring things together: its own code does not compile, or a conflict is waiting and it has no agent. This is the one place, and the only one, where the conflict is handled. All the others simply receive the team version once it is clean.
Meanwhile, the sync dot shows “Agent is resolving a conflict…” on the integrator’s side, and the other members can read “X is integrating the changes.”
The check that protects the team version
Section titled “The check that protects the team version”A merge is accepted only if two conditions are met: it must be saved, and the project must compile. If the result does not compile, the merge is cancelled and sent back to the agent.
The same process handles merges that have no text conflict but whose result no longer compiles — the typical case where two people each renamed and used the same thing on their own side.
As a result, the team version can be behind, but never broken.
The only case where you have to act
Section titled “The only case where you have to act”If no agent is available in the project, nobody can merge. The sync dot then shows, for the members concerned:
“Conflict to resolve — launch an agent”
All it takes is for one of the two to launch an agent in the project. Their computer takes over the bringing-together, the agent is called in automatically, merges, then goes back to what it was doing. An agent you just opened and haven’t asked anything yet is fine.
If no agent takes the conflict within the minute, the app puts your files back the way they were before. No conflict marker remains in your code, and saving on your computer continues. The online backup, however, waits for an agent to settle the conflict. Nothing is lost.
The app makes sure you don’t miss it:
- After about a minute with no agent, a notification stays displayed at the bottom right: “Version conflict: launch an agent”. It explains: “two versions of the same file don’t agree, between two of your devices or with a teammate. The online backup is paused.” Its Show project button brings you back to the project’s agents. The app does not launch an agent on your behalf.
- If the conflict is still open after ten minutes, whether or not an agent is handling it, it reminds you every ten minutes: “Version conflict for 10 min” — “the online backup is still paused. Check on the agent’s progress, or launch another one.”
- The sync dot turns red, and the project tab shows “Version conflict pending.”
While the conflict waits, the rest of your work does not reach the teammate you are in conflict with either, and you do not receive theirs: your work is integrated as a single block. Everything moves again as soon as the agent has merged.
A busy agent is never interrupted for this: the app picks an idle agent. See Launch and steer your agents.
When your work is waiting with someone else
Section titled “When your work is waiting with someone else”If you are not the computer that gathers the work, your code is saved on your side, but it is only part of the team version once it has been integrated. When this wait goes beyond a few minutes, the sync panel no longer says “Your code is saved and synced”: it shows “Your work is waiting to be integrated for 5 min”, with what it knows about the reason.
| Message shown | What it means | What to do |
|---|---|---|
| “X’s app, which gathers everyone’s work, seems stuck. Let them know.” | X’s computer is no longer moving forward, often a conflict is waiting | Ask X to check their sync |
| “X, who gathers everyone’s work, does not have the project open.” | X has closed the project or the app | Wait: another computer takes over |
| “It’s X’s app that gathers everyone’s work.” | X is working, your work has not gone through yet | If it lasts, check with X |
| “Automatic retry.” | The app does not know which computer gathers the work | Nothing, it retries on its own |
Nothing is lost in the meantime: your work stays saved on your side and online.
Two other blocks that look like a conflict
Section titled “Two other blocks that look like a conflict”| Message shown | What it means | What to do |
|---|---|---|
| “Publishing blocked: conflict markers in … — fix them, then publish again.” | Conflict markers were saved into the code | Fix the named files, then Publish now |
| “Publish on hold: the code doesn’t compile — ask an agent to fix the error, and publishing resumes on its own.” | The team version only moves forward if the code compiles. A coding agent is running in the project | Ask the agent to fix it |
| “Publish on hold: the code doesn’t compile — launch an agent to fix the error, or fix the file yourself. Publishing resumes on its own.” | The same block, with no coding agent running in the project | Launch an agent, or fix the file yourself |
This block applies to every member, whether or not they gather the team’s work: code that does not compile stays on your computer. It is saved on your side, but it is not sent to your teammates, and their agents are not disturbed to fix it. Meanwhile, your teammates keep exchanging among themselves; you receive their work once your code is repaired.
The “Publish on hold” line follows compilation live: it disappears as soon as the code compiles again, and publishing resumes right away. When a compilation error lasts, the app saves a version and starts a sync without waiting for the next cycle: the line appears even if the project is idle.
Two warnings after an integration
Section titled “Two warnings after an integration”These two notifications stay displayed until you close them.
| Message shown | What it means | What to do |
|---|---|---|
| “A teammate’s work couldn’t be integrated” | On the gathering computer: a teammate’s work stays saved on their side, but it is not in the team version | Nothing: integration is retried at their next change. This is also what shows when their work does not compile |
| “N file(s) removed from your folder” | You had changed these files, and the version that was just synced no longer contains them. They left the folder, not the history | Open Versions and restore the version that contained them to get them back |
Limits
Section titled “Limits”- Two people cannot drive Roblox Studio at the same time on the same project. The app warns: “Two people are syncing this project,” names who drives which places, and asks that a single person drive all of them. See Sync, explained.
- Working as a pair on the same task does not work. A code conflict can be merged; two different visions of the same feature cannot. Split up the topics.
- Code written outside VibeStarter will be overwritten. A partner who changes the project’s files with another tool does not take part in this process.