Remote access is Tailscale's job now. The relay runs on the same host as the
backends it fronts, binds loopback only, and never sees a tunnel, so everything
that existed to enrol a remote machine and dial it back is dead weight.

Removed:
  - clients/: 38 files of machine-side launchers, supervisors and FRP tunnel
    plumbing, superseded by the host deployment script
  - relay machine enrolment: the OAuth device-code flow, /api/machine/*, the
    console's Machines and Pending sections, and the frp-ssh transport payload
  - relay/deploy/deploy-relay.sh and docs/windows-relay-oauth-spec.md

Kept, because "machine" means two different things here: in the app it is the
user-facing name for a relay target, and that vocabulary stays. machine-status-
monitor.mjs probes each declared target and is unrelated to enrolment; it stays
wired to the target registry, though nothing reads its cache until the multi-
backend work lands.

State files written by the tunnel-era relay carry a machines array. Rather than
reject them, validateState drops the field and migrates to version 3, so an
existing deployment keeps its owner credential and paired devices on upgrade.

Tests: 53 -> 50. Five machine-enrolment cases in pairing-store and one machine
OAuth case in passkey-pairing were removed; three new cases replace them, each
verified to fail against the pre-deletion tree: the enrolment routes now 404,
a tunnel-era state file upgrades without losing devices, and an unknown state
version is still rejected rather than silently treated as a fresh install.

…value

The suite has been red on this branch since the iOS bundle identifier was set
to a personal one: the test still pinned the upstream placeholder. Every
deployment signs with its own id, so pinning any single value reddens the suite
for whoever changes it next. Assert a well-formed reverse-DNS identifier
instead, which still fails on an empty or single-segment value.

Running the real relay shows these paths answer 401, not 404: once the pairing
controller stops claiming a route, the request falls through to the relay's own
bearer check. The 404 in this test is the fixture's fallback for an unclaimed
route, which is a statement about the controller rather than about deployed
behaviour. Name and comment now say so.

… a proxy

Brings up the backends, the relay, and HTTPS on the tailnet in one command.
There is no reverse proxy and no certificate to renew: tailscaled terminates
TLS for the host's own *.ts.net name, which also means nothing listens on a
public interface. Measured on this machine, `tailscale serve` streams SSE
without buffering -- one event per second arrives at 1.001s intervals, 11ms
behind a direct connection -- so the proxy it replaces was only adding a hop.

Two modes. production installs launchd jobs and supervises the backends;
`--managed-backend name:port[:profile]` registers each one as its own relay
target, which is how a client gets a switchable "machine" per profile. shadow
installs nothing and runs beside a deployment that is already serving devices,
registering its backend with --target instead of taking it over, so a new build
can be exercised without touching the live one.

Three rules the scripts enforce rather than document:
  - no path is hardcoded. The Tailscale CLI lives inside the app bundle, and
    /usr/bin/git may be an xcode-select shim that fails; both are probed.
  - ProcessType never reaches a plist. Background puts a job in a throttled
    band where a Node service needs over 90s to bind its port.
  - verification goes through the tailnet name, never 127.0.0.1, because the
    loopback path skips both TLS termination and the proxy hop.

Renders launchd jobs from a module with tests rather than a heredoc, so the
ProcessType ban and the supervision keys are asserted; one test round-trips
through plutil to prove macOS can parse what we write.

Verified by installing, killing the relay to confirm launchd restarts it, and
uninstalling to exit 0 with no residue.

The relay answered its own OPTIONS preflight but forwarded the upstream
response verbatim, so a client with a real origin cleared the preflight and was
then blocked from reading the body. Measured against a live backend: the
preflight carried access-control-allow-origin, the GET that followed carried
nothing. From the client side that looks like a hang rather than a policy
error, which is an expensive thing to debug from inside a renderer.

Supply the header only when the backend did not, so a backend started with
`opencode serve --cors` keeps its own policy instead of being overridden.

The desktop shell loads from its own scheme and is the first client this
affects; phones were unaffected because a native fetch enforces no origin.

…nding layer

The window loads the same React bundle the phone runs. `expo export --platform
web` produces a plain static site, so components, store, themes and business
logic are shared rather than reimplemented; the shell only does the three
things a page cannot do for itself.

Serves the bundle from a registered `cockpit://` scheme rather than file://,
whose null origin the relay's CORS policy cannot name and which disables the
storage APIs the UI uses. Keeps the renderer sandboxed with node integration
off, and exposes three named functions across the bridge instead of a channel
the page can send anything down.

The keybinding layer is the substantive part. A terminal owns every key and a
window does not: tab moves focus, ctrl+w closes the window, ctrl+p prints, and
the leader itself -- ctrl+x -- is Cut inside a text field. 44 chords are claimed
before their default action runs; ctrl+v is deliberately not among them because
opencode's own table marks paste as non-preventing.

Same-chord-different-meaning needed a context model. Taking the table at face
value produced 13 collisions, e.g. ctrl+d as exit, delete-session and
delete-stash at once. Splitting each dialog into its own context and naming the
six list-scoped actions whose names do not reveal their scope brings it down to
three, each irreducible: the upstream table binds <leader>q twice, and up/down
are cursor movement or history depending on where the cursor sits, which is a
runtime fact. A test pins that set, so a fourth cannot appear quietly. Conflicts
are reported rather than resolved by parse order, because the losing action
becomes unreachable and nobody would know.

Verified by running it: the window paints, renders the real UI, and reports no
page errors. The smoke mode asserts on errors the preload actually collects,
not on an array nothing writes to.

Not yet wired: the page receives the dispatched actions but does not consume
them, and the first screen is still the bundle's own Hosts view rather than a
purpose-built host-and-profile picker.

The desktop shell resolves a key against opencode's table and sends back an
action name like session_compact. The app speaks a different vocabulary --
command-palette ids, entrypoints, and a few things only the session screen can
do -- so without a translation the shell would claim the key and nothing would
happen, which is worse than leaving it unbound.

An action absent from the table resolves to `unsupported` rather than being
dropped, so a key that does nothing can say so instead of looking broken.

The mapping is checked rather than trusted: a test walks every target and fails
if it names a command or entrypoint that does not exist. A typo there compiles
cleanly and then silently no-ops at the one moment a user is watching. Verified
by planting one: a single misspelling turns three tests red. Two further tests
assert the reverse direction, that no palette action or entrypoint has been left
without a key.

The bridge itself is inert when the host object is absent, so the phone build
needs no platform branch at the call sites, and a throwing handler is reported
instead of tearing down the subscription -- one bad action should not leave
every later key dead.

… nobody can

Three outcomes: the store does it now, a screen that registered a handler does
it, or nobody can yet. The third is the reason this exists. A key that silently
does nothing is indistinguishable from a broken keyboard, so an action no one
claims is reported with why -- no session open, no screen mounted, or not in
the mapping at all.

Session-scoped actions are refused before they reach a store method that would
throw on a missing session, which is what pressing escape on the host list used
to do.

One test walks the lookup tables against the capability table: a name present
in one and missing from the other would otherwise only surface as a crash at
the moment a key is pressed.

Completes the chain the shell started. A screen registry holds the actions only
a mounted screen can perform, a performer calls the store method or the screen
handler, and a hook mounts the whole thing once at the root. The hook is thin
because translation, routing and performing are pure modules with their own
tests; it only subscribes while the app is mounted and reads the store at press
time rather than closing over a stale snapshot.

Nothing is allowed to vanish. An action with no open session, no mounted screen,
or no mapping reports why, because a key that silently does nothing is
indistinguishable from a broken keyboard. Async store actions that reject are
surfaced rather than left as unhandled rejections.

The registry keeps the newer screen's handler when navigating between sessions:
the second screen mounts before the first unmounts, so a stale dispose must not
remove the live handler.

Verified by pressing a real key in a real window, not by asserting on a mock.
The smoke run sends Escape through Electron's input pipeline and diffs the page
before and after; one line appears, "interrupt needs an open session", which
exists only in the new performer. Its presence proves every link fired: key
interception, keymap resolution, IPC, translation, routing, the store write and
the re-render. The successful-mutation branch is unit-tested but was not the
path this observable exercised.

…keys to resolve against

Two pieces, found in that order.

The transcript list is inverted: the newest message sits at native offset 0 and
older content at larger offsets, so page-up moves toward older by *increasing*
the offset. Getting that backwards is silent, so the arithmetic is a tested
module rather than inline in the component, with clamping at both ends and a
guard for metrics that have not been measured yet. The component advances its
own record of the offset immediately after issuing a scroll, because key repeat
outruns the native scroll event and reading the stale value would make every
press after the first a no-op.

Then the measurement that mattered: pressing PageUp in the real window changed
nothing, and the reason was not the scrolling. Keys are resolved against the
surface the user is on, and nothing had ever told the shell what that was, so
every key resolved as 'global' -- where no transcript, prompt or diff binding
exists. Every context-scoped binding in the table was unreachable. Screens now
declare their surface for as long as they are mounted, and the value is replayed
to a shell bridge that attaches later, since the two mount in either order.

Verified that the previously working path still works: Escape in a real window
still reports "interrupt needs an open session" end to end. PageUp moving a live
transcript is covered by unit tests and by a measured resolution table -- it
resolves to nothing in 'global' and to messages_page_up in 'messages' -- but has
not been watched against real content, which needs a paired host in the shell.

A host can run several backends side by side, one per profile, and the relay
exposes each as its own target. The store already discovers them with their
reachability, so this only shapes what the screen shows and what it refuses.

Two decisions live here rather than in a component. A host with no machine stays
visible with the reason it has none, because hiding it looks like the host was
never added, and the two kinds of nothing -- answered but authorized nothing
versus never answered -- read very differently to someone debugging. And a host
running more than one machine is flagged, because every machine on a host shares
one session database: the same session appears under each of them, so choosing a
machine picks which process runs the next prompt, not which sessions exist. That
is the one thing this screen has to say out loud rather than let a user discover
by seeing their session listed twice.

The screen component and its routing are not here yet; this is the part that can
be tested without one.

A laptop reaches several backends on one host, and which one runs the next
prompt is a choice worth making before a session is on screen. The desktop shell
now loads this route at launch; the phone keeps its existing tabs, where the
sessions screen already offers a per-machine filter and a first screen would be
one more thing to dismiss.

The screen opens straight through when a host has exactly one reachable machine,
because a picker with a single option is a dialog, not a choice. When a host
runs more than one it says that they share a session database, so seeing the
same session under each machine reads as expected rather than as a bug.

Two defects that only a real window showed, both now fixed: the route rendered
with a stray "devices" header because it was never registered in the stack, and
the empty state printed its reason twice, once as a subtitle and once in the
body. Verified after the fix by launching the shell and reading what the window
actually painted.

Upstream refused both on purpose: a phone was a monitor, not a development
machine. A laptop reaching the same host is a development machine, so the two
hardcoded refusals are replaced by real calls. The API layer already had both;
only the store said no.

A created session carries the machine it was created on. Without that it would
be routed to whichever backend answered first, which on a host running several
profiles is not the one the user picked.

startNewSessionPrompt no longer states something untrue. It clears a stale error
banner so the screen offering the choices opens clean; creation itself is
createSession.

The two tests asserting the refusal are replaced by three asserting the
capability, including that a refused creation reports itself and returns no ref
rather than handing back a reference to nothing.

Directory and machine are selectable at creation. Agent and model are not yet:
they are chosen per session after it opens, and wiring them into the creation
call needs the picker UI that does not exist yet.

The data was already there: the store fetches a session's diff when it opens and
keeps it current from the event stream. Only the screen was still rendering a
hardcoded sample, with a subtitle that said so.

The page is addressed by route rather than reading whichever session happens to
be active, so a diff opened from one session cannot show another's changes. With
no session in the route it keeps the fixture, which is what the copy-QA page and
its existing test rely on, and it now distinguishes "this session has no changes"
from "this is the sample" instead of showing sample changes for an empty session.

The session screen claims the diff entrypoint, so the desktop keybinding that
resolves to it has somewhere to go.

Two things this turned up. The screen's test never mocked expo-router or the
store, so pulling either into the module graph broke the suite at import time
before a single test ran. And SessionRef requires a machine id, which a route
parameter cannot promise, so the absent case is now explicit rather than passed
through as undefined.

Machine, working directory, agent and model go in, but they do not leave
together. Creating a session carries the machine and the directory; the agent
and the model are applied to the session once it exists, because that is how the
backend models them. So this returns both halves, and a caller that uses only
the first silently drops what the user picked.

Agents and models come from the chosen machine's execution contract. A machine
whose contract has not arrived can still be chosen but can offer neither list,
and saying so beats rendering two empty dropdowns that look like a machine with
no agents.

The configured default model is a bare model id while a picker key carries its
provider, so the default is matched on the id. Comparing the two strings would
never match and the default would quietly become whatever sorted first.

A choice the machine does not offer is refused by name rather than dropped, and
a blank directory falls back to the machine's own rather than sending an empty
string for the backend to interpret.

The screen is not here yet; this is the part that can be tested without one.

Collects the four choices and then does the two-step the backend requires:
create carries the machine and directory, and the agent and model are applied to
the session once it exists. Getting only the first half right would look like
the pickers did nothing.

The agent and model lists come from the machine's execution contract, which is
cached per machine and directory rather than per session, so a new session can
read one an earlier session already fetched. When none is cached the screen says
the machine has not reported its agents and that the session will start on its
defaults, instead of rendering empty lists that read as "this machine has none".

session_new no longer routes to the store. Creating a session needs four choices
that only a screen can collect, so the key now opens that screen; the store keeps
the creation call itself. The desktop's first screen claims the key.

Two things this turned up. Importing the store into a screen test pulls React
Native into the graph and fails on a missing __DEV__ global before any test
runs, so the scope-key helper is mirrored in the mock instead. And only machines
that are actually answering are offered, since creating a session on an
unreachable one fails after the user has made four choices rather than before.

Three gaps and one measurement.

The new-session key only worked on the screen that claimed it, which made it
dead everywhere else. Opening a screen is an app-level concern, so the root
claims it now and the key works from any surface.

On a fresh install nothing has ever cached a machine's execution contract, so
the agent and model lists would have stayed empty forever and the four-choice
form was really a two-choice one. Fetching a machine's agents and providers is
not a session operation, so the store now asks the machine directly and caches
the result under the same key a session would have used.

The desktop app can be installed: one command builds the renderer, packages a
.app, and then checks the artefact rather than the exit code -- an Info.plist
macOS cannot parse produces a bundle that fails to launch with no useful
message. Verified by running the packaged binary, not the dev build: it paints
the machine picker with no page errors. Unsigned, so the first launch needs
right-click then Open.

And the question that has been open since the multi-profile design was written:
two backends on one session database. Measured in an isolated data directory
that never opens the real one. Started together, the second dies with "database
is locked" and never binds a port. Started after the first is listening, both
run, and fifteen rounds of concurrent writes produced no lock contention in
either log with the database in WAL mode. So it works, but they must not
initialise at the same time -- the deploy script already starts them one at a
time, while launchd at boot does not, and relies on KeepAlive restarting the
loser ten seconds later. That last part is inference, not measurement, and says
so in the docs.

Two traps found along the way, both recorded: macOS /tmp resolves to /private/tmp
and the server stores the resolved path, so a query with the unresolved one
matches zero sessions rather than erroring; and session listing is scoped by the
server's own working directory, which a directory query does not change.

The smoke could only send one chord, so every leader binding -- twenty-eight of
them, including the one that creates a session -- was unverified in a real
window. A comma now separates chords in a sequence.

Pressing ctrl+x then n moves the window from the machine picker to the new
session screen, which proves five things at once that unit tests cannot: the
leader chord is taken before the text field treats it as Cut, the pending state
survives between two key events, the sequence resolves to session_new, the
action reaches the claim at the root rather than dying on whichever screen is
mounted, and the screen it opens actually renders.

The relay normalises a missing allowedDirectories to an empty list, and an empty
list forbids every directory. The deploy script omitted the field, so every
fresh host produced an owner client that answered directory-scoped requests with
403 directory_forbidden. Writing null, which means any directory, fixes it.

Found by running the app's live end-to-end test against a real deployment: it
connected, discovered the machines, and then failed on the first scoped call.

The deploy script's own verification had passed throughout, because it only ever
made unscoped requests. It now asks for a directory explicitly, so this class of
failure surfaces at deploy time instead of on a user's first real call. The
check is known to fail on the old configuration: that is exactly the 403 the
end-to-end run produced before the fix.

A hiddenInset title bar floats the window buttons over the page, and the page
starts at the top, so the app title rendered underneath them.

The strip is reserved in the shell rather than in the shared UI, because the
phone renders that same UI and the space would be dead margin there.

The smoke now reads the computed padding back and fails if it is missing. The
injection is a side effect with no return value to check, so without this a
failed injection would look exactly like a successful one.

The deploy script never generated a bootstrap key, so the pairing console could
not register an owner and the QR flow was unreachable. Pasting a 64-character
token by hand was the only way to add a device, which is not a flow anyone would
use on a phone.

The key is generated once and preserved across redeploys, and the script prints
a one-time setup link. The secret travels in the URL fragment, which browsers do
not send to the server, so it never reaches an access log; the relay stops
accepting it the moment an owner passkey exists.

Verified against the running relay rather than by reading the code: the correct
key returns a WebAuthn ceremony whose relying-party id is the tailnet hostname,
and a wrong key of the same length is refused with 403.

…nnot drift

Hiding the title bar and reserving room for the window buttons are one decision,
but they lived in two places: a style on the window and a CSS injection fifty
lines away. Shipping the first without the second is exactly what put the
traffic lights on top of the app header.

Both now come from one function, and a test asserts the pairing on every
platform rather than only the one this machine runs: the inset is required
exactly when the title bar is hidden, the CSS exists exactly when the inset is
required, and an unrecognised platform falls back to a real system title bar
rather than to buttons floating over the content.

Windows still has no real-machine check. It takes the system title bar, which
draws above the page instead of over it, so the overlap cannot occur by
construction -- but that is reasoning, and the test only guards the decision,
not the rendering.

The pairing endpoints were same-origin by construction: no allow-origin header,
Cross-Origin-Resource-Policy set to same-origin, and a preflight handler
covering exactly one route. That holds for the console, which the relay serves
itself, and fails for every separate client -- including the packaged desktop
app, which loads from its own scheme.

An Authorization header is not CORS-safelisted, so even a GET is preflighted;
the single-route handler left the rest unreachable. The preflight now covers
/api/*, and JSON responses carry allow-origin with a cross-origin resource
policy. A wildcard origin cannot be combined with credentials by any browser,
so this does not expose the console's cookie session to another origin.

Found by driving the real UI in a browser against a live relay: six console
errors on /api/pairing/me. After the fix the same call returns a readable 401,
which is correct -- a static token client is not a paired device -- rather than
being blocked before the answer arrives.

The first screen only read cached relay targets and nothing ever populated
them on a cold start, so a healthy relay was reported as "no machine
authorized". The hosts tab worked because tapping a host runs the check;
the new screen had no equivalent. Set the active connection and refresh
once per connection whose targets are unknown, and say so on screen while
it runs.

Also replace the titlebar smoke assertion, which measured the wrong thing.
It read the computed padding on body, which proves the injected CSS parsed
but not that any content moved. Measure the viewport position of the
topmost visible text instead, and record the root elements' positioning so
a future regression is diagnosable from the artifact.

Two places replied to OPTIONS. The pairing module sees the request first, and
its /api/ branch spelled out a narrower list of its own: it allowed only
Authorization and Content-Type, and dropped PATCH. It therefore shadowed the
proxy's correct answer for every API route.

The desktop app sends X-OpenCode-Target and X-OpenCode-Directory, so the
browser blocked its requests before they were sent and the app could only
report "Failed to fetch". Nothing else noticed: curl does not enforce CORS, and
the phone loads a page the relay itself serves, which is same-origin and never
preflights.

Move the policy into lib/cors.mjs and have both callers use it. Responses now
also expose X-Next-Cursor, without which a cross-origin reader sees null and
the paged session list stops after one page.

The test that was missing reads the client's own source and fails if a custom
header it uses is neither allowed nor exposed.

The packaging script was macOS only: the platform flag, the bundle layout, the
plist lint and the du call all assumed an .app, so there was no way to produce
a Windows build at all. What differs between the targets now lives in
package-target.mjs, and the script takes --platform. Cross-building win32 from
the Mac host works and needs no Wine.

Both icon containers are derived on every build from the phone app's existing
artwork, which is the icon its author agreed we could use. One source image
means macOS and Windows cannot end up on different art. The .ico is assembled
here because the format is a header followed by whole PNG files, and pulling in
an image library to write sixteen bytes of it would be the larger cost.

The smoke also stops measuring the wrong things. It now asserts where the
topmost visible text actually landed rather than that a padding rule parsed,
and it makes that assertion on every platform: macOS must clear the floating
window buttons, and everywhere else the same inset would be dead margin. It
captures the page again once the network has settled, because first paint
showed a spinner and reading it as the finished screen reported a healthy app
as broken.

An empty list was always explained as "this relay authorized no machine for
this device", which reads as a permissions problem. The usual cause is a
request that failed with a message the screen never showed, and the wrong
explanation sent this investigation toward relay permissions while the real
error sat unread in the store.

Pass the host's sync error into the model and show it.

Three of its checks could not report a problem, and one of them had already
been read as evidence.

The page's error and action lists were handed to the renderer through
contextBridge, which deep-clones what it copies. The page therefore held a dead
snapshot: every later push landed in the preload's world and was invisible in
the one the check read. The console-error assertion had been passing against an
array that could never fill. Both lists are exposed as functions now, which the
bridge proxies live.

Synthetic key presses named their modifiers the way a binding spells them, and
sendInputEvent ignores a name it does not know. "ctrl" was such a name, so the
modifier vanished and the press landed as a bare letter; a smoke that pressed
nothing of the sort still reported the screen had changed. Names are translated
now, and an unrecognised one fails the run instead of being dropped.

Adds a click step, because screens reachable only by pointer cannot otherwise
be keyboard-tested, and records which actions the shell delivered, because "the
key never resolved" and "it resolved and nothing handled it" look identical
from outside and need opposite fixes.

The native project is untracked, so the two constraints that make it build are
invisible: a path without non-ASCII characters, because CocoaPods reads the
Podfile through Ruby and fails on the first non-Latin byte, and a post_install
that lifts pods whose declared deployment target predates what Xcode accepts.
Both were found the hard way.

A free Apple ID signs an app for seven days and an installed copy cannot be
extended, so every renewal is a full rebuild and reinstall. Doing that by hand
meant remembering the team, the scheme, the configuration, and which device id
to pass; getting one wrong produced either a build against the wrong signing
identity or a silent no-op.

The script finds the connected phone by the shape of its UDID rather than by
the wording of devicectl's state column, which differs depending on how the
phone is attached. It reads the expiry out of the profile the build actually
embedded and refuses to install something that is already expiring: a stale
profile on disk otherwise produces an app that stops launching within hours.

…or a path

Creating a session meant typing an absolute path, which on a phone means
recalling one exactly. "/~" looks like the obvious shorthand and the relay
rejects it, because it is not an absolute path; the app then showed the bare
token directory_forbidden, which reads as a demand for a directory rather than
as a statement that the one given is not usable.

The machine already knows where its sessions live. Those directories are now
offered one tap each, busiest first, with the machine's own default at the top,
and the field says what leaving it empty does. The relay's rejection tokens are
translated where they surface.

…stination

A locked or half-attached iPhone still appears in devicectl's list, marked
unavailable. Taking its id regardless handed xcodebuild a destination it could
not match, and the error it printed talked about destination specifiers and
listed every simulator on the machine, which says nothing about the phone being
locked.

The device is now chosen from the physical entries that are not unavailable,
and an attached-but-unusable phone is reported as exactly that.

The README opened in English with a template's description of itself. It now
says in one paragraph what the thing does for the person reading it, and names
the project it started from: BB-84C's opencode-mobile-solution, whose relay and
phone client this fork builds on, and whose app icon it uses with permission.

The empty state said the relay backend cannot look up past edits. That was
wrong, and it was wrong because the probe behind it asked the wrong path: the
client reaches this endpoint at /session/{id}/diff, while the probe used
/api/session/{id}/diff, which no route serves and which the backend answers
with its web app's index page, at status 200. The same mistake made session
deletion look broken when it works.

The endpoint answers with JSON. Why a given session has no recorded changes is
not something this screen knows, so it no longer guesses.

Running bare `opencode` on the host starts its own process with its own
session database, so nothing it does is visible from the phone. This
attaches to the backend already running on 4096, which is the one the
phone and every paired client talk to, so all of them see one session
list.

The script was referenced in deploy-notes as living in ~/.local/bin and
had never been in the repository, so cloning the repo did not give you
the command the notes told you to run.

Credentials are read from backend.env into the environment rather than
passed on the command line, so they stay out of ps and shell history.
It also supplies --dir when the caller omits it: the backend partitions
sessions by working directory, and without it the list belongs to the
service process's own directory rather than the project you are in.

A client running Shadowrocket or Clash builds its own utun and takes
over the default route, so packets bound for the tailnet are swallowed
before Tailscale sees them. The symptom is a connection that times out
rather than one that is refused, and none of it is visible from the
host, which reports every service healthy.

Three causes present identically. The document separates them with one
command, because the fixes have nothing in common: a VPN stealing the
route is a client rule change, an address collision can only be fixed on
the router, and a blocked data plane is a NAT setting.

Two findings are recorded because they cost real time. Shadowrocket's
tun-excluded-routes reads like "leave this range alone" but means "hand
this range to the physical NIC", and the global route it installs
outranks the scoped route Tailscale relies on, so it makes things worse
rather than better. And curl ignores the client's rules entirely because
it reads proxy environment variables, which produces a GUI that works
while every command line request hangs.

A turn that fails server-side is reported as an event, not as a failed request:
the machine emits session.error and carries on. The app handled message, status,
question and todo events and silently dropped that one, so an unavailable model
produced no reply, no error, and no change on screen. Measured against the live
host: prompting with a model that does not exist returns 204 and then emits
session.error twice, carrying "Model not found: <provider>/<model>".

The event now lands in the session's error channel and clears the busy status,
so the spinner stops. The error text is read defensively, because a shape this
app does not recognise still has to say something rather than nothing.

That channel also rendered under a fixed "Transcript refresh warning" label
while every writer puts a self-describing sentence into it, so a model error
read as a transcript problem. The label is gone.

…h it

The friend's repo investigated an iOS 27 launch crash reported against a
TestFlight build from July. The root cause is not established there — no
termination report was available — and their own device opened the app fine
after updating. What they prepared is compatibility rather than a proven fix:
Expo 57.0.23 with aligned native modules, and expo-build-properties with
ios.enableSceneSupport, because Apple requires the scene lifecycle for anything
built against the iOS 27 SDK.

Merging the whole of upstream rather than cherry-picking the two iOS lines
costs one conflict and keeps the fork close enough to sync again later. The
conflict was complementary: both sides had added an event handler at the same
place, ours for session.error and theirs for permission.asked, so both stay.

Our bundle identifier stays com.skylerhu.opencodemobile, which is what makes
the next install an upgrade rather than a second app with empty storage.
Version moves to 1.1.0: upstream's own app.json still says 1.0.0, and a
separate number says plainly that this line carries their work plus ours.

Counted from the diff rather than recalled: 41 files, +3598/-50, 27 of them new
and none removed. Almost all of it is a desktop keyboard layer the phone never
loads; what a phone user actually sees extra is the machine picker, the new
session screen, the command palette, and four additions inside the session menu.

Records the three deliberate divergences, with the reason for each: our bundle
identifier, which is what keeps an install an upgrade; our version line; and the
dropped VPS-era client directories.

createSession defaulted title to the literal 'New Session' and always sent it. The OpenCode core auto-names a session only while its title matches its own placeholder (^(New session - |Child session - )<ISO8601 with ms>Z$), so every session opened from the app stayed unnamed, with no error and no log line. Send title only when the caller chose one; an explicit title is still sent and still wins.

Tests assert the request body: no title sends {}, an explicit title is kept, the session handed back still carries the server placeholder, and the missing-directory guard still throws. Against the pre-fix client, two of the four fail.

npm test on the merge result: 436 passed, 4 skipped. typecheck: the 2 pre-existing errors in pairing.test.ts, unchanged.

Needs an app rebuild and reinstall to reach a phone. Sessions already titled 'New Session' are not renamed retroactively.

…sign it so alerts reach Notification Center

Ctrl+C / Ctrl+A on Windows and Cmd+A on macOS are no longer claimed by the TUI keymap, and a right-click menu offers copy and select all. Closing the window hides it to the tray or menu bar; the tray, the Dock, a second launch and a notification click all reopen it, and a crashed renderer is rebuilt. The app starts at login by default, with a tray toggle. Packaged macOS builds are re-signed ad hoc under their own bundle id, since a build signed as "Electron" is never registered for notifications.

…ssions everywhere

On iOS a whole message now renders as one UITextView (react-native-uitextview), so a selection can start and end anywhere inside it, across paragraphs, lists and code blocks. Select text opens the whole loaded conversation, scrolled to the message, for selections that span messages; the message card keeps a permanent ... button instead of a long press. Permission and question requests are kept per directory, so a parent session shows its subagents' requests and can answer them. A global event stream feeds a waiting badge on the session list, an in-app banner, and desktop notifications that open the session.

The English README, docs/architecture.md and relay/README.md still described the VPS relay, the SSH/frp tunnel, machine enrollment and the clients/ launchers, all removed when this fork moved to a single host on the tailnet. They now describe the host deployment, tailscale serve, the desktop client, the event streams the 2.0 features rely on, and how to build each part from source, since no public binaries are published. The product spec's transport diagram is updated and its broken links to the UX spec are fixed.