Merge main and reduce the change to the defect that reproduces: the server's
synchronous login-shell probes (env snapshot and command -v for opencode,
node, bun) ran with no timeout, so a slow or interactive rc file held startup
until it returned — on macOS that is what made a brew-installed opencode look
undetected from a Dock launch. Every probe now carries the same 5s bound the
Electron shell probe already uses and falls through on overrun; the known
install locations already include both Homebrew prefixes.
The non-login command -v fast path and the reproduction script are dropped:
a plain sh inherits the same PATH the resolver has already walked.
Closes#1720
Merge main and reshape the follow opt-out to the gestures the timeline was
missing: a middle-button press starts the platform autoscroll pan (the only
scroll gesture on wheel-less mice and tablets with a pointer), Shift+Space
scrolls up from the keyboard, and an upward wheel over a nested scroller that
still has room above stays with that scroller instead of releasing the chat.
The grace re-pin timer and scroll-direction tracking are dropped: returning to
within the end band already re-arms follow, and the mode machine is built
without timers on purpose. Pause/Break never move the viewport and are not
gestures.
Closes#1640
The list's animated maintainScrollAtEnd is single-flight and re-pins only
within a tenth of the viewport, so in a narrow viewport (VS Code sidebar) each
revealed block — several screens tall there — left the reader a second behind
and multiple screens above the live edge. The timeline hook now follows growth
itself: glide when within a viewport of the end, otherwise jump to one screen
above the end and glide the rest. Measured at 420x640: time spent >40px behind
dropped from 45% to 11%, max distance from 1682px to 382px.
Claude-Session: https://claude.ai/code/session_017TK5JAYDfT3Fotc23UEg98
Chat sessions without a project were dropped from the mobile session tree
because no registered project owned their directory. The sheet now partitions
sessions like the desktop sidebar and shows Chats as a collapsible section above
the project tree, with the same rows, swipe actions and paging; search results
label them "Chats" instead of the raw directory name.
Claude-Session: https://claude.ai/code/session_017TK5JAYDfT3Fotc23UEg98
With "Follow new content while streaming" disabled, sending from mid-history
no longer anchors the new message at the top of the viewport; the reader stays
where they were and the scroll-to-bottom pill leads to the new turn. Sending
from the live edge still parks the message as before. The setting's info text
now describes this in every locale.
Claude-Session: https://claude.ai/code/session_017TK5JAYDfT3Fotc23UEg98
Chromium scrolls overflow:hidden ancestors when a textarea caret moves out
of view (PageUp/PageDown in the prompt box, long prompts), shifting the whole
app up and hiding the title bar with no way to scroll back. Snap html/body/#root
back to zero on any root scroll event in the web, desktop, VS Code and mini-chat
apps.
Claude-Session: https://claude.ai/code/session_017TK5JAYDfT3Fotc23UEg98
The VS Code app mounts VSCodeLayout, which exposes sessions, chat, and settings but not the shared GitView or its branch selector. The remote-tracking checkout path added for that selector therefore had no user-reachable caller in the extension.
Restore the existing VS Code checkout implementation and remove the VS Code changelog claim. The web runtime keeps the fix because its Git view exposes the branch selector.
CodeMirror collapses a CRLF pair into one line break, so the document is
shorter than the string it was given. The composer derived the caret from
the JS string length, which put it past the end of the document and made
dispatch throw `RangeError: Selection points outside of document`.
Because the exception fires before the transaction applies, the document
never updates, the un-normalized text stays in React state, and the draft
persists as-is: every later visit to the session restores it and crashes
again, with no way out from the UI.
Derive the caret from the change set instead, in the controlled writeback
and in the imperative insert/replace handles.
fixes#3013
# Conflicts:
# CHANGELOG.md
# packages/vscode/CHANGELOG.md
Since opencode 1.18.x, `POST /global/upgrade` requires a `target` semver in
the body. OpenChamber sent an empty object, so every "Update OpenCode" click
came back 400. The rejection arrives as `{name, data:{message}}`, which has
no `error` field, so the user was left with the bare status text: "Bad
Request".
Resolve the target from the latest release — the same lookup the upgrade
prompt already uses to decide there is anything to offer — and fail with an
explicit code when it cannot be resolved, rather than sending a body opencode
is guaranteed to reject. Read the upstream rejection message so a refused
upgrade explains itself.
The VS Code extension carries its own copy of this flow and had the same two
defects; both are fixed there.
fixes#3121
Canonical answer to 'is this reachable in VS Code': three webview hosts,
VSCodeLayout's three views, a 33-row surface table (mounted / partial /
not mounted with the mount chain or cut-off point), the dead-bridge
handler list, and which fs routes stay live. Reviews, changelog entries,
and parity claims consult this map; whoever mounts or unmounts a surface
updates it in the same change.
- changelog-authoring: a VS Code entry requires the surface to be
mounted from the VS Code entrypoint (consult the surface map in
packages/vscode/src/DOCUMENTATION.md when present); shared-but-unmounted
code earns no entry
- triage-prs: yulia-ivashko is a core maintainer with merge rights —
her review decisions carry maintainer weight in sweeps
A shared component importing a runtime API proves nothing about that
runtime; the runtime's own entrypoint must mount the path. Trace
top-down before claiming a bug or fix is user-visible in a runtime —
VS Code's layout mounts only a subset of the shared surfaces and bites
reviews constantly.
Either the manual check guards an irreversible path and the verdict
reads 'MERGE — after you verify X', or the verdict is a plain MERGE
with no checklist: residual cosmetic risk is absorbed by the verdict
(users surface it, a revert costs one commit). Post-merge homework
lists were the reviewer offloading uncertainty onto the maintainer.
A manual check either guards an irreversible path (data loss, upgrade
and restart flows, auth) and gates the merge, or it is low-risk visual
polish where merging first is fine and skipping the check is stated as
accepted risk — never a ritual list padded to feel thorough.
- PRs/issues with human thread activity run in pickup mode across all
three skills: the output opens with thread state (asked / answered /
resolved at HEAD / remaining) and continues the conversation instead
of restarting review — the sweep remembers the maintainer's own
comments for them
- every PR/issue reference in maintainer-facing output is a clickable
markdown link, never a bare number
- report entries are calibrated: 2-4 sentences each (what, why this
verdict, main risk), needs-your-hands lives inside the entry rather
than a number-repeating section
"Restart to Update" answered the renderer with null before the install was
attempted, so a rejected install only reached main.log and the button looked
dead. The apply-update path now keeps the IPC call open until the app quits or
autoUpdater reports the failure, rolls the quit/install flags back when the app
stays up, and the update dialog shows the real reason with a translated hint for
a rejected code signature.
Also settle the download promise on downloadUpdate() itself: an already cached
payload emits no 'update-downloaded', which left that promise pending with its
listeners attached on every retry.
A sweep verifies whether an earlier push-back or recorded product
decision was addressed at the current HEAD and reports that explicitly;
it never re-decides or re-asks. The generic rebase-request is never
posted over an existing substantive review comment.
Conversation-style entry points so the maintainer can start real work
without opening the GitHub UI: feature-work serves a menu of accepted
features (approved scope from the acceptance comment is binding);
bug-work serves verified bugs from the local fix backlog and the
root-cause:found label, severity-first, re-verifying anchors before
fixing. Both close the loop with fixes #N in the eventual commit.
A maintainer's answer on a FEATURE-DECISION now resolves mechanically:
wanted features get an acceptance comment plus the new accepted label
(never re-asked by later sweeps; label:accepted is the implementation
roadmap), declined ones get the drafted close; conditional answers are
recorded as the accepted scope.
triage-issues gains a silently-fixed detection ladder, strongest
evidence first: mechanism-anchor (git log -L on the root-cause:found
file:line since the issue date), repro re-run against current main, and
symptom search over commits/CHANGELOG/merged PR titles. CLOSE-FIXED
always names its evidence; an unverified hunch only asks the reporter
to retry.
pr-review's merge verdicts now search open issues for the symptom a bug
fix resolves and propose Closes #N, so fixes stop landing unlinked.
Bohdan Triapitsyn