Using the workspace
Sessions working together
How Dus sessions in one project see and message each other, claim files before editing, share ports and numbers, wait for merges, and the Team view that shows it all.
You can run many sessions in one project at once: one fixing a bug, one building a feature, a scheduled job, a session in the terminal. Each usually works in its own worktree, so they can't overwrite each other's files on disk. They can still clash: two sessions changing the same function, both adding migration number 12, both installing packages, both starting a dev server on the same port. Dus sessions coordinate so that doesn't happen.
Open Team in the sidebar to see it.
What sessions do for each other
| What happens | |
|---|---|
| See each other | When a task starts, Dus is told which other sessions are working, on which branch, on what, and which files they claimed or changed. |
| Claim before editing | Before changing files another session might touch, Dus claims them (files, folders or single functions). Another session's edit to a claimed file is held back before it happens, never silently overwritten. |
| Spot clashes early | Dus is warned when a change touches a file another session changed but hasn't merged, a file that depends on one (from the repository index), the same lockfile, the same migrations folder or a generated file. |
| Message each other | Sessions can ask and tell each other things ("are you changing the login form?"). Replies are threaded. |
| Share resources | Ports, migration and decision numbers and locks (a test database, seed data) are reserved, so two sessions never take the same one. Package installs and migration commands take the project's install or migrations lock by themselves. |
| Wait and merge in order | A session can wait for another to merge, finish or free some files, and carry on by itself when it does. When a session merges, every session whose work overlaps is told to bring the base branch in first. |
| One writer in the main checkout | Only one session at a time changes files in the project folder itself. Others there can still read; isolated sessions are never held up. |
When a session's edit is held back, Dus chooses what to do: wait for the other session, agree a split by message, do other work first, or ask you. If you say go ahead, Dus shares the claim, which always asks you first.
Messages are not you
A message from another session appears in the chat as a card, From Billing page, never as your words. It carries no authority:
- It can't approve anything. If another session asks Dus to run a command, Dus asks you before running it, whatever your permission mode, and the approval says which session asked.
- A session can't ask another to do what it may not do itself. A session in Plan mode can't ask others to change files, and a command you declined in one session can't be requested from another.
- Secrets are masked in messages, the same way as everywhere else (vault).
Messages are short (up to 4,000 characters) and limited, so sessions can't talk in circles: a few a minute, two broadcasts per 10 minutes, and when two sessions exchange 10 messages in 10 minutes without settling it, Dus is told to stop and ask you. A message never wakes an idle session or spends money by itself; it is read at that session's next step.
The Team view
Team lists every session working in this project, including those started from the terminal or another window:
- Sessions: what each one is doing, its branch, the files it claimed (with a button to release a claim) and the files it changed that aren't merged yet. Its helper workers and parallel attempts are listed under it. Sessions that stopped show how long ago; one that stopped unexpectedly has its claims released automatically.
- Overlaps: where the work of two sessions meets, and why it matters.
- Reserved: ports, numbers and locks, with a Release button for anything stuck.
- Messages: what the sessions told each other, and who is waiting for whom.
- Merge order: which session should merge first when their work overlaps.
Releasing a claim or a reservation tells its session at its next step.
Work already in flight, from any tool
Dus also knows about work that isn't a Duscode session: another tool's worktree (for example a Claude Code agent's in .claude/worktrees/), a colleague's branch that isn't merged yet, an open pull request, a ROADMAP line marked in progress, or a decision drafted on a branch. Before it starts or queues a request, it checks. If the request overlaps, it tells you at once, for example:
This is already being built on branch worktree-agent-adde… by a Claude Code agent (Instant replies…), last commit 20 min ago, not merged yet.
Then it asks whether to wait for it, build on top of it after it merges, or do only the part that doesn't overlap. It never builds or queues a duplicate silently. Team lists this work under Being built elsewhere.
The project home
A new session opens on the project home, above the message box and the suggestions:
- The project: its name, branch, last activity and architecture.
- Continue where you left off: this project's sessions, Needs you first, then In progress, then Done but not finished. All projects and sessions opens the full list in Projects.
- Work in progress elsewhere: worktrees and branches with unmerged work from any tool, with the latest commit, how many files changed and how long ago.
Continue here on a worktree starts a Duscode session in that worktree instead of a new one. Nothing in it changes when you do: no branch is created or renamed, and deleting the session later leaves the worktree and branch as they were. Dus's first step reads the branch's recent commits and changes, so it picks up where the work stopped. It is refused while another session or Duscode window works there, and it asks first if files there changed in the last two minutes, since another tool may still be writing.
Things to know
- Everything is kept in
.duscode/coord/in your project, which is never committed. Nothing leaves your machine. - A session that stops unexpectedly is noticed at once on the same computer; a silent one after about 45 seconds. Its claims, locks and waits are released then. A session that comes back after a restart keeps its place.
- Claims expire after 2 hours without activity; editing a claimed file renews it.
- Workers and parallel attempts belong to their session: they never block each other or the session, and when a worker's work is merged its claims become the session's.