A development report on SessionDock, based on the project state of September 5, 2026. SessionDock is not yet a released, end-to-end application.
Two agents are supposed to work on two projects in parallel. Each needs a browser with a prepared login. If its assigned workspace is busy, neither agent should silently switch to another profile or browser.
Separate browser profiles solve only one part of this problem: they separate browser data. We also need to know which project a workspace belongs to, who may control it at any given moment, and what should happen to a delayed action after control changes hands.
SessionDock is our attempt to answer those questions in software. We are developing a local Linux environment for prepared Chromium workspaces that a person will eventually be able to delegate to an agent for a limited time. The main state-management and scheduler components are implemented and tested. The path from the user to a real browser action is not yet complete.
If all you need is to keep two logins apart, you do not automatically need another tool. Our starting point is also a separate Chromium user-data directory. A launch script can open two browsers with different directories and assign matching download paths.
The additional requirements appear when a workspace no longer belongs to one person alone, but is used by different actors at different times.
Consider a simple example. A person signs in to an administration interface and then delegates a limited task to an agent. During the task, the person needs to inspect something and takes control back. A browser action prepared by the agent arrives late.
The browser data may still be perfectly separate. One question remains: Is the agent still allowed to execute that action?
A directory structure cannot answer this. The system needs an authoritative record of who currently controls the workspace.
SessionDock calls a prepared browser workspace with its own assignment and local data a slot.
In the current workspace code, each slot receives a complete Chromium user-data directory, a download directory, and separate XDG and D-Bus paths. The graphical design uses a private Weston desktop. The packaged browser is Chromium, not Google Chrome.
The scheduler adds a fixed binding to this technical separation. The data model includes the project, worktree, environment, expected account, and expected tenant. An agent run receives permission for a specific binding; it should not be free to select an arbitrary environment on every request.
The word “expected” matters. A stored account name does not prove that the website is actually signed in with that account. The full login, confirmation, and delegation flow has not been integrated yet.
Likewise, a worktree assignment is currently a data-model concept in the tested core. It does not mean that SessionDock can already discover every Git worktree and open the appropriate interface automatically.
A person and an agent should not write to the same slot at the same time. The scheduler therefore uses exclusive, time-limited access rights: leases.
A lease epoch complements that model. It is a monotonically increasing generation number for control authorization. When control changes hands, the previous generation becomes invalid.
Before dispatch, the state machine checks whether the agent still has control, whether the session is ready, and whether the expected lease epoch matches the current one. This core logic is covered by unit tests.
That does not yet prove an end-to-end protected browser action. The check must sit at the correct point in the complete execution path, and that integration remains open.