* fix(ui): reveal overlay scrollbar on hover or active scroll (re-port to bindScrollbar)
Re-ports #2825's container-hover reveal onto the rewritten bindScrollbar
architecture that landed on main after the original PR branch was created.
- pointerenter/pointerleave on the scroll container reveal the thumb
immediately (deliberate intent on every mouse-pointer runtime; inert
on touch via an event.pointerType === 'mouse' guard, since the Pointer
Events spec fires pointerenter on touch taps as well)
- hide-timer re-checks pointerOverContainer at fire time, so the thumb does
not vanish when the pointer moves from container onto the sibling thumb
- suppressVisibility (chat auto-follow) still suppresses hover reveal
- on hover, schedule a re-measure so the horizontal thumb reflects the
current geometry: if the container has horizontal overflow the thumb is
revealed, otherwise it stays hidden. This matches the original PR's
updateMetrics() approach and avoids the regression where onScroll (which
does not measure) would leave a legitimately overflowing horizontal
thumb hidden while hovering
- index.css: drop the Settings-specific overlay-scrollbar display:none
(thumb is never permanently visible anywhere now)
- regression tests: horizontal thumb reveals on hover when overflow exists,
stays hidden when it does not; touch pointerenter is inert; hand-off
race (container pointerleave followed by thumb pointerover) keeps the
thumb visible; pointerleave hides the thumb
* ci(ui): add overlay scrollbar interaction recording workflow
Records the hover-reveal/hide interaction of the overlay scrollbar
(PR #3219 re-port to bindScrollbar) as a webm + GIF via Playwright
recordVideo, converted with ffmpeg palettegen/paletteuse.
- scripts/record-overlay-scrollbar.mjs: drives hover in/out, forces
overflow on the first .overlay-scrollbar-target so the demo works on
a clean data dir, exports overlay-scrollbar-hover.{webm,gif}.
- .github/workflows/interaction-recording.yml: mirrors the validated
screenshots.yml pattern (auth disabled server, Playwright chromium,
15-min timeout), adds ffmpeg install step.
* docs(ui): add overlay scrollbar interaction recording
Animated GIF captured by the interaction-recording workflow (Playwright
recordVideo + ffmpeg) showing the hover-reveal/hide behavior of the
re-ported overlay scrollbar (bindScrollbar): thumb fades in on pointer
enter, hides again after the hide delay once the pointer leaves.
* feat(ui): adopt ScrollableOverlay in remaining native-scroll panels
Extends the overlay scrollbar (hover-reveal, hide-on-leave) to panels
that still used native overflow-y-auto scrolling:
- Sidebar (left nav): outer flex-1 scroll region
- ContextSidebarTab: full-height tab content
- SessionSwitcherDropdown: session list dropdown (preserves contentRef
for scrollIntoView / switcher item queries)
- HelpDialog: help content region
All four merge sizing into outerClassName (flex-1 min-h-0 / h-full /
max-h-[60vh]) and keep visual classes on className, with disableHorizontal
where the original hid horizontal overflow. Type-check passes; unit test
failures in OverlayScrollbar.test.tsx and event-pipeline.test.js are
pre-existing (reproduce on pristine HEAD).
* test(ui): flush hide timer before asserting thumb hidden
The hide path always schedules a setTimeout (hideDelayMs: 0 still
schedules a 0ms timer). happy-dom runs real timers, so the test must
let the macrotask fire before asserting dataset.visible — flushing rAF
frames alone is not enough. Fixes the one failing test in
OverlayScrollbar.test.tsx (12/13 -> 13/13).
* fix(ci): make scrollbar interaction recording hover retry across targets
The record script picked the first .overlay-scrollbar-target and moved the
pointer to its center; layout/hydration order varies between CI runs, so
the hover sometimes landed on a target whose thumb cannot reveal (empty
container), failing the run. Now it iterates targets in DOM order until
the vertical thumb actually appears (or fails after exhausting all).
* fix(ci): record workflow + i18n + overlay-chrome hide
- .github/workflows/interaction-recording.yml: drop 'ref: rework' so the
workflow checks out the PR head SHA on upstream (where 'rework' branch
does not exist). Replace with persist-credentials: true.
- packages/ui/src/lib/i18n/messages/tr.ts: add 4 missing gitView.empty
keys (parity fix, only tr.ts was behind en.ts). Translations are
approximate; the parity test only checks key existence.
- scripts/record-overlay-scrollbar.mjs: on a fresh data dir the web
build can render onboarding modals (ChooserScreen, AboutDialog,
ConfigUpdateOverlay) that float above the MainLayout with a blurred
backdrop. The thumb's isThumbVisible() returns true (DOM-mounted)
but the captured frame is dominated by the modal, so the user sees
'dialog in front, blurred background' instead of the scrollbar
reveal. hideOverlayChrome() injects CSS to hide every plausible
overlay root and best-effort closes known UI store dialogs.
* fix(ci): drop fork-specific ref in record workflow + add tr locale gitView.empty keys
- .github/workflows/interaction-recording.yml: drop 'ref: rework' so the
workflow checks out the PR head SHA on upstream (where 'rework' branch
does not exist). Replace with persist-credentials: true.
- packages/ui/src/lib/i18n/messages/tr.ts: add 4 missing gitView.empty
keys (parity fix, only tr.ts was behind en.ts). Translations are
approximate; the parity test only checks key existence.
- scripts/record-overlay-scrollbar.mjs: hide onboarding chrome (modals,
backdrops, dialogs) that float above the MainLayout when recording
against a fresh data dir, so the captured GIF shows the actual
scrollbar reveal instead of a blurred-overlay dialog screen.
- docs/interaction-recordings/overlay-scrollbar-hover.gif: regenerate
(489 KB) with overlay chrome hidden (same artifact as CI run
33507731092 which passed).
* ci: noop push to retrigger 'pr checks' on a fresh runner
The 'pr checks' check on this PR's prior head (0509212c3) failed with
'releaseJob is not a function' in packages/web/server/lib/walkthrough/
routes.test.js. This test lives in upstream main and is not touched by
this PR's diff. The same flake is currently hitting PR #3265 and
feat/scheduled-preflight-gate.
Confirmed the two latest upstream main commits (bec7a82568 sidebar
sort, 40e4b6f857 request-security) do not touch walkthrough/, so the
failure is a 20ms timing flake in the test's executor Promise, not a
code regression. This empty commit triggers a new CI run on a
different runner with a different scheduling window.
* feat(settings): adopt ScrollableOverlay in settings shell and dialogs
Several settings surfaces still rendered their scroll containers with
native browser scrollbars (overflow-y-auto / overflow-y-scroll), which
read inconsistently against the overlay scrollbar used everywhere else
in the app once content exceeded the viewport.
Wrap the relevant containers in <ScrollableOverlay>:
- SettingsView: nav sidebar (mobile), mobile fallback, mobile page
sidebar, mobile page content, and desktop split view
- DirectoryExplorerDialog: results list
- GitHubIntegrationDialog: issues / PRs list
- GitHubIssuePickerDialog, GitHubPrPickerDialog: lists
- NewWorktreeDialog: form body
The settings sub-pages (OpenChamberPage, VoiceSettings, PasskeySettings,
etc.) do not carry their own overflow — they inherit the scroll host
from SettingsView, so the shell change is sufficient for them.
type-check, lint, and ui tests (368/369, the one failure is a pre-existing
event-pipeline flake unrelated to this change) all pass.
* ci(record): re-run overlay scrollbar recording on a fresh runner window
* ci(record): give overlay thumb 1500ms to reveal on hover
The 'hover did not reveal the thumb on any target' check has been
flaky across runs since the workflow landed in this branch (about
half the runs fail with the same error). 700ms was tight on cold
GitHub-hosted runners; 1500ms absorbs the cold-start variance
without changing what the GIF captures (the thumb's hide animation
runs after pointerleave, unaffected by the longer pre-leave wait).
* ci(record): debug thumb visibility timing on hover
* ci(record): drop debug logging, keep 1500ms hover wait
Debug logging was used to identify that 200ms is enough on a
healthy runner, but 700ms was not. The flake was the OpenChamber
server being slow to initialize the OpenCode side on cold
runners — the thumb itself renders quickly once the app is up.
Keeping 1500ms absorbs that cold-start variance without slowing
successful runs by more than the GIF's existing post-hover
animation wait (1000ms hideDelayMs).
---------
Co-authored-by: sergiofspedro <sergiofspedro@users.noreply.github.com>
Co-authored-by: openchamber-ops <ops@openchamber.dev>
Co-authored-by: Bohdan Triapitsyn <artmore@protonmail.com>
OpenChamber is an open-source workspace for running and reviewing AI coding work on desktop, web, VS Code, and mobile.
Start agent work, see what changed, and take it through review and release. Your projects and sessions remain available when you switch devices or step away.
More screenshots
What you can do with OpenChamber
Goals that continue on their own
Give a session a finish line with Session Goals. OpenChamber checks the result after every turn and keeps the agent working until it completes the goal, gets blocked, or reaches the limit you set. It can continue after you close the app.
Compare and combine runs
Use Multi-run to give the same task to up to five models, each in its own session and optionally its own worktree. See what each one actually built, choose the best result, or use Fusion to combine the strongest parts into a new session.
Guided changes walkthroughs
Changes Walkthrough turns a large diff into an AI-guided tour of the change. It groups related edits into steps, puts them in the order the change makes sense, and explains how the pieces fit together.
Inspect a running app
Open your app beside the conversation with Preview. Point at an element to send the agent its screenshot, styles, position, and browser errors. No more trying to explain "this thing here." The desktop app can do the same with any web page in its built-in browser.
GitHub context from issue to pull request
Start a session from a GitHub issue or pull request with its context attached. Send failed checks or review comments back to the agent, then update or merge the pull request from OpenChamber.
Continue on another device
Open the same projects and sessions from Desktop, Web/PWA, VS Code, iOS, or Android. Check progress, answer questions, review changes, and reattach to a running terminal.
Private remote access
Pair a device with a one-time QR code and connect through Private Relay without opening ports or exposing a public server. The connection is end-to-end encrypted and can be revoked at any time. Direct connections, LAN/VPN access, Cloudflare/Ngrok tunnels, and SSH are also supported.
Track work across projects
See which sessions are working, waiting, finished, or failed, along with approvals, scheduled tasks, provider limits, token use, and costs. Organize sessions into folders and keep notes, todos, and reusable project actions nearby.
Schedule recurring work
Run a prompt once, daily, weekly, or on a cron schedule. Scheduled tasks can use Session Goals, so they continue toward an outcome instead of stopping after one response.
Use it where you work
Surface
Role
Desktop
The complete workspace for macOS, Windows, and Linux, with multiple windows, Mini Chat, remote machines, SSH, and native notifications
Web / PWA
Open your workspace in a browser, install it as an app, and stay up to date through background notifications
VS Code
Keep sessions beside your code, send selections to the agent, open results in the editor, and compare parallel runs
iOS / Android
Review and steer work away from your desk, receive completion alerts, and use the terminal with touch controls
CLI / Server
Run OpenChamber on a workstation or server, schedule work, manage remote access, and keep it available after login
Quick start
Desktop for macOS, Windows, and Linux
Download the latest release from GitHub Releases. Desktop bundles the matching OpenCode CLI, so no separate OpenCode installation is required.
Linux releases are available as x86_64 and ARM64 AppImages. Make the downloaded AppImage executable and keep it in a writable location for in-app updates:
OpenChamber uses OpenCode to run coding agents. We chose it because it is open source, has a solid API, and is easy to extend.
OpenChamber handles the rest of the workflow. You can decide what to try, keep the agent on track, review the result, connect from another device, and ship the change.
OpenChamber is an independent project and is not affiliated with the OpenCode team.
Contributing
See CONTRIBUTING.md for development setup and contribution guidelines. Documentation authoring guidance lives in packages/docs.
Acknowledgments
Special thanks to:
OpenCode for the API and open-source architecture OpenChamber builds on
Pierre for the diff viewer and syntax highlighting
The T3 Code team for their browser adapter for libghostty-vt, which our terminal is built on
Yulia Ivashko, who built the firework celebration that plays on every successful push
Everyone who contributed code, reported bugs, or shared ideas
