* fix(ui): keep PWA dialogs visible on Android
The PWA dialog adjustments under
@media (display-mode: standalone) and (max-width: 768px) were originally
written to clear the iOS status bar / notch by adding a top offset and a
translateY override. The rule was not scoped to iOS, so Android PWAs
matched it too:
- The extra top: 50% + (safe-area-top * 0.22) plus
--tw-translate-y: -50% + (safe-area-top * 0.6) pushed the dialog
below the visible center on Android, where the parent already centers
the popup via flex items-center justify-center on Base UI's portal.
- max-height was computed against 100vh. Android Chrome's collapsible
URL bar makes 100vh larger than the visible viewport, so when the
bar is shown the dialog's action buttons can be pushed off-screen
(for example the Install button in the Skills install dialog).
Fix:
- Use 100dvh (with the existing safe-area subtractions) so max-height
tracks the dynamic visible viewport on Android.
- Move the top / --tw-translate-y override into
@supports (-webkit-touch-callout: none) so it only applies on iOS,
where it was always intended.
Verified by rebuilding packages/web and inspecting the emitted CSS:
the common .pwa-dialog-content rule now ships with max-height using
100dvh and no top/translate overrides; the iOS-only block keeps the
original offsets.
Tested manually on Android Chrome PWA against
https://aion.xsim.uk: 'About OpenChamber' and 'Install skill' dialogs
now center vertically and their footer buttons stay on-screen as the
URL bar collapses/expands.
* fix(ui): restore vh fallback for PWA dialog max-height
Address review feedback on #1370: the previous patch dropped the
original `max-height: calc(100vh - ...)` line entirely and only kept
`100dvh`. On browsers that do not understand the `dvh` unit the
declaration is invalid and dropped, which would leave the dialog
without any `max-height` cap inside this media block — potentially
worse than before the fix.
Reinstate the canonical progressive-enhancement pattern: ship the
`100vh` declaration first so older engines have a usable value, then
override with `100dvh` on the next line for browsers that do support
it. New comment makes the two-line pattern explicit so it isn't pruned
again as accidental duplication.
Verified via `packages/web` build: the emitted CSS now contains both
declarations in order on the shared `.pwa-dialog-content` rule:
max-height: calc(100vh - ...);
max-height: calc(100dvh - ...);
`type-check` and `lint` in `packages/ui` remain clean.
---------
Co-authored-by: lilyzhaun <lilyzhaun@users.noreply.github.com>
Run OpenChamber and OpenCode as separate persistent services — useful when you want to access your
dev machine over a VPN (e.g. Tailscale) or LAN without a Cloudflare tunnel.
How it works:
OpenCode runs as its own service, binding only to localhost.
OpenChamber connects to it via OPENCODE_HOST and --host 0.0.0.0 makes it reachable on your VPN IP.
--foreground keeps the CLI process alive so systemd can track and restart it.
Why set PATH and SSH_AUTH_SOCK?
systemd user services start with a minimal environment — no shell profile is sourced.
Without an explicit PATH, OpenCode won't find tools installed via Homebrew, npm, or ~/.local/bin.
Without SSH_AUTH_SOCK, git operations over SSH (push, pull, clone) will fail because the agent socket isn't inherited.
Adjust the PATH to match your own tool installation paths.
%t expands to $XDG_RUNTIME_DIR (e.g. /run/user/1000), where most SSH agents write their socket.
OpenChamber will be reachable at http://<your-vpn-hostname>:3000 from any device on your VPN.
Note:--host 0.0.0.0 is required to listen on all interfaces. The default
bind address is 127.0.0.1 (localhost only). Use --host <ip> or
OPENCHAMBER_HOST=<ip> to bind to a specific interface instead.
Managed-local path note: OPENCHAMBER_TUNNEL_CONFIG must point to a path inside the container user home (/home/openchamber/...). If your Cloudflare config references a credentials JSON file, that file path must also be accessible inside the container (mount with volumes).
Website docs source lives at packages/docs/content/docs/reverse-proxy.mdx.
Tunnel behavior notes
OpenChamber supports one active tunnel per running instance (port).
Starting a tunnel with a different mode/provider on the same instance replaces the current tunnel.
Replacing or stopping a tunnel revokes existing connect links and invalidates remote tunnel sessions for that instance.
Connect links are one-time tokens; generating a new link revokes the previous unused link.
Data Directory Permission Note: The data/ directory is mounted into the container for persistent storage (config, sessions, SSH keys, workspaces). Before running, ensure the directory exists and has proper permissions:
My wife, who - with zero AI background - sat down with the app for the first time and built the firework celebration that plays on every successful push.
Every contributor who shaped this project with their PRs, ideas, and attention to detail.
