DevLobby 1.2.0

A repository row that can be a whole folder of them, and a paste that arrives once.

What changed

A row can be the folder your projects live in

Projects do not always sit one to a folder. Point DevLobby at the directory
they live in, turn on Repositories inside, and that one row watches every
work tree under it and publishes their sum — ahead, behind, staged, dirty,
untracked, conflicted, all of it added up. Dropping such a folder on the window
does the same thing without being asked, because a directory that is not a
repository but has repositories in it can only have meant that.

The sum is an ordinary repository state under the folder's own path, which is
the whole trick: the header's chips, the spine colour and the row itself go on
reading one flat state and need no idea any of this happened. Only the branch
slot differs — a folder has a count to put there rather than a name, unless
every repository in it really is on the same branch, which is worth saying when
it happens. Rest the pointer on the chips and a card lists what it was summed
from, worst first: anything unreadable or half-merged at the top, then whatever
owes the most, and the clean ones settled alphabetically behind a count. A
repository that could not be read is named there but left out of the totals,
because adding its zeroes would report a folder as clean on the strength of the
half of it nobody could see.

Thirty repositories in a folder is thirty git status calls and thirty watch
handles, so the cost is held down three ways: the membership is capped, members
poll on a floor of their own rather than the window's interval — their .git
watches keep them responsive without it — and that floor is jittered per path
so they do not all come due on the same tick for the rest of the session.
Folders are walked again on a slow backstop; Refresh is what you press when you
have just cloned one.

Separately, the browser skill now installs into every Claude profile on the
machine rather than into ~/.claude alone. Two accounts side by side is two
configuration directories, and a skill written into one is invisible from the
other — which failed in the worst available way, because the first profile
answered for the machine, the bar found nothing left to do and took its own
install button off the screen, so the session that could not find
/devlobby-browser had no way to ask for it.

Ctrl+Shift+V no longer pastes the clipboard twice

Paste into a CLI running in a pane and the clipboard arrived twice, bracketed
once and then again, so the prompt read every line of it doubled.

xterm has no paste binding of its own. It sends ^V for Ctrl+V and leaves the
chords people actually paste with to the browser, picking the paste event back
up through a listener on its own textarea. Chromium's default for Ctrl+Shift+V
is a paste, so that path was already complete before DevLobby did anything —
and DevLobby's own handler, which reads the clipboard through the main process
rather than letting the page near it, was a second one on top of it.

The two only coexisted because of how app chords are kept alive. A terminal's
custom key handler returns false for a chord DevLobby owns so the event can
still reach the window, and returning false makes xterm bail out before its
own cancel() — no cancel is no preventDefault, so the browser went on to
run its default over the paste that had just happened. A chord we take now
cancels its own default.

Download

devlobby-1.2.0-setup.exe	installs to your own user folder, so it never asks for admin, and adds Start Menu and desktop shortcuts
devlobby-1.2.0-portable.exe	one file, no install, no shortcuts

Windows x64. Your repositories, notes and layout live in %APPDATA%\DevLobby,
and upgrading over 1.1.1 leaves them alone.

If Windows blocks it

These builds are unsigned, so SmartScreen warns on first run — More info,
then Run anyway. Smart App Control, where it is enforced, judges each binary
by its hash and can refuse outright with "An Application Control policy has
blocked this file". Building from source and launching through devlobby.cmd
runs the same app through Electron's own signed binary, which that policy does
not object to:

npm install
npm run build
devlobby.cmd

The README has the screenshots
and the full tour.

DevLobby 1.1.1

One crash, arriving five seconds after the thing that caused it.

What changed

Closing a browser pane no longer takes the window with it

Open a link in a pane of its own, close that pane, and five seconds later the
whole grid went black — every terminal, every page, gone from the screen. The
delay is the reopen window running out, which is what finally lets go of a
closed pane, so the crash arrived long after the click that caused it and
looked like nothing in particular.

Every <webview> method that reaches the guest — executeJavaScript among
them — begins by asking the element for the guest's id, and that throws once
the element has left the document. Synchronously, before there is a promise,
so a .catch() hung off the call never saw it. React runs a deleted
component's effect cleanups after it has removed the node, so a pane being
torn down was cancelling its Ctrl watcher against an element whose guest had
already gone — and an exception in a cleanup is one React has nowhere to put.
With no error boundary above it, it unmounts the root, and an empty root is a
black window.

Only a pane that had been somewhere could do it. The Ctrl watcher returns
early on about:blank, so a browser pane opened and never pointed anywhere
registered no cleanup to throw from — which is why a link, arriving with a URL
already on it, was the way to find this. Closing a whole grid with such a pane
in it did the same thing.

Nothing was actually lost when it happened: the shells kept running in the
main process behind the blank window. It was the grid you could no longer see.

Every injection now goes through one helper that turns that synchronous throw
back into the rejection the rest of the picker already knew how to ignore, and
npm run check:browser runs the real functions against an element that throws
the way a detached one does.

Download

devlobby-1.1.1-setup.exe	installs to your own user folder, so it never asks for admin, and adds Start Menu and desktop shortcuts
devlobby-1.1.1-portable.exe	one file, no install, no shortcuts

Windows x64. Your repositories, notes and layout live in %APPDATA%\DevLobby,
and upgrading over 1.1.0 leaves them alone.

If Windows blocks it

These builds are unsigned, so SmartScreen warns on first run — More info,
then Run anyway. Smart App Control, where it is enforced, judges each binary
by its hash and can refuse outright with "An Application Control policy has
blocked this file". Building from source and launching through devlobby.cmd
runs the same app through Electron's own signed binary, which that policy does
not object to:

npm install
npm run build
devlobby.cmd

The README has the screenshots
and the full tour.

DevLobby 1.1.0

Five things that were quietly wrong, and a link that now goes somewhere.

What changed

A link that wants a new tab

target="_blank" did nothing at all, and the cause was a single attribute.
React discards a boolean given to an attribute it does not recognise, and
webview has no hyphen in it, so it was never a custom element to React —
allowpopups never reached the DOM, and Chromium refused every new tab in the
page before Electron could be asked about it.

It is now a question with three answers: a browser pane of its own beside
the page you were reading, nothing at all, or nothing from that pane for
five minutes — which is the one you want on a site that opens a tab every
time you touch it. No window is ever opened either way.

Hold Ctrl over a page

The same element picker, a modifier away. Hold Ctrl over a page and the
crosshair appears; click and the comment box opens on what you pointed at. It
is one comment and then it is over — no mode to enter, and none to leave. The
existing Select Element is still there for a sitting.

Comments are kept

They go into the state file with the layout, so they survive quitting DevLobby
and come back with the pane. A pane — or a whole grid — still holding comments
no session has collected asks before it closes, because a page you have marked
up is the one thing in a browser pane that reloading cannot get back.

The comments button turns everything off

One press of ⌖ puts the panel, the crosshair and a half-written comment box
away together. It used to close only the panel while leaving the page in pick
mode, which hid the very button that would have turned the selector off.

Clicking a tab stopped reordering the strip

A press was only cleared once it had become a drag, so an ordinary click left
one standing, and the next sweep of the pointer across the strip was read as
that press continuing. Grids are numbered by position when unnamed, so the
strip went on reading "grid 1, grid 2" while the two of them traded contents.

Also: a pane's URL is no longer wiped by its own guest reporting that it
arrived at about:blank before anything had pointed it anywhere, which could
cost a restored pane its page.

Download

devlobby-1.1.0-setup.exe	installs to your own user folder, so it never asks for admin, and adds Start Menu and desktop shortcuts
devlobby-1.1.0-portable.exe	one file, no install, no shortcuts

Windows x64. Your repositories, notes and layout live in %APPDATA%\DevLobby,
and upgrading over 1.0.0 leaves them alone.

If Windows blocks it

These builds are unsigned, so SmartScreen warns on first run — More info,
then Run anyway. Smart App Control, where it is enforced, judges each binary
by its hash and can refuse outright with "An Application Control policy has
blocked this file". Building from source and launching through devlobby.cmd
runs the same app through Electron's own signed binary, which that policy does
not object to:

npm install
npm run build
devlobby.cmd

The README has the screenshots
and the full tour.

DevLobby 1.0.0

A repo-aware tiled workspace for terminals, browsers, and AI coding sessions.
Every pane knows the repository it sits in and what that repository's working
tree is doing, and says so in its header. A pane that wants you — it rang the
bell, or went quiet on a question — glows red and flashes the taskbar, so the
whole grid can be left running while you get on with something else.

A pane can also be the page you are building: it tiles like the rest, keeps a
log of every request the page makes, and hands any one of them — or a run of
comments pointing at elements on the page — to a Claude session two panes over.

Download

devlobby-1.0.0-setup.exe	installs to your own user folder, so it never asks for admin, and adds Start Menu and desktop shortcuts
devlobby-1.0.0-portable.exe	one file, no install, no shortcuts

Windows x64. Your repositories, notes and layout live in %APPDATA%\DevLobby,
and uninstalling leaves them alone.

If Windows blocks it

These builds are unsigned, so SmartScreen warns on first run — More info,
then Run anyway. Smart App Control, where it is enforced, judges each binary
by its hash and can refuse outright with "An Application Control policy has
blocked this file". Building from source and launching through devlobby.cmd
runs the same app through Electron's own signed binary, which that policy does
not object to:

npm install
npm run build
devlobby.cmd

What is in it

• A tiling grid: drag a pane onto another to split, drag the gutters to resize,
  one keystroke to fill the window. Nothing restarts while you rearrange.
• Tabs, each one a whole grid of its own, all of them still running while you
  are looking at another.
• Git state per pane: branch, staged and unstaged counts, untracked count, and
  drift against the upstream.
• A browser pane with device viewports, an element picker that collects
  comments, and a network log you can read the whole exchange in.
• /devlobby-browser, a Claude Code skill the app installs for you, which
  collects those comments from whichever pane you marked up.
• Notes that tile and persist like terminals, and an undo that brings back a
  closed pane — or a whole grid — with its shell still running.

The README has the screenshots
and the full tour.