* fixed workflow
* fix(forge): hoist staged ACP node_modules to stay under Windows MAX_PATH
The Squirrel/nuget Windows maker failed with 'path too long': stageAcpAdapters
rebuilt the ACP dependency closure by always nesting each dep under its parent,
producing 5-level chains (codex-acp -> open -> wsl-utils -> is-wsl ->
is-inside-container -> is-docker) whose paths hit ~260 chars on the CI runner and
blew past Windows' MAX_PATH (nuget.exe ignores long-path settings).
Hoist every package to the top-level node_modules npm-style, nesting only on a
genuine version conflict. Deepest staged path drops 177 -> 114 chars (worst-case
CI absolute ~197, well under 260). Add verifyAcpStaging() which asserts every
dependency edge resolves, in the staged tree, to the same version as the source
pnpm tree, failing the build loudly instead of shipping a broken installer.
* fix(code-mode): make packaged code mode work via on-demand engine provisioning
Packaged builds could never run code mode: the Claude/Codex ACP adapters are
spawned as separate `node <entry>` processes resolved at runtime, but esbuild
can't inline a dynamic spawn target and Forge strips the workspace node_modules,
so every release threw `Cannot find module '@agentclientprotocol/...'`. Dev
worked only because of the pnpm symlink.
Rather than bundle the ~400 MB of native engines (one claude + one codex binary
per OS), provision them on demand:
- forge.config.cjs: stage the two ACP adapters + their JS dependency closure into
.package/acp/node_modules (npm-style nested layout, native engines skipped),
exempt .package from the node_modules ignore rule, and only sign/notarize when
APPLE_ID is set so unsigned local/CI builds can package.
- agents.ts: resolve the adapter from the staged location first (node_modules
fallback in dev); provision the pinned engine and point the adapter at it via
CLAUDE_CODE_EXECUTABLE / CODEX_PATH. No dependence on a user's global install.
- engine-provisioner.ts: ensureEngine() downloads the per-platform engine package
from npm AT THE EXACT VERSION THE ADAPTER WAS BUILT AGAINST, verifies its sha512
integrity, extracts atomically into ~/.rowboat/engines/<agent>/<version>/, and
caches it. Version-pinning keeps the ACP handshake compatible.
- engine-manifest.ts + scripts/gen-engine-manifest.mjs: committed manifest of
tarball URLs + integrity for all platforms, regenerated from the adapters'
pinned versions on a bump.
Verified on macOS arm64: both engines provision and run, and both adapters
complete the ACP initialize handshake from the packaged .app against the
provisioned engines. Installer drops from ~790 MB to 390 MB.
* feat(code-mode): explicit per-agent Enable in Settings; no silent chat download
Code mode now requires the user to explicitly enable an agent before use, instead
of silently downloading a ~200 MB engine on the first chat message.
- Settings → Code Mode: each agent shows "Not enabled" + an Enable button that
downloads its engine with a live progress indicator (download % → verify →
install), then flips to "Engine ready". Driven by a new codeMode:provisionEngine
IPC call + a codeMode:engineProgress push channel. The section now states the
prerequisite explicitly: the agent must be installed (Enable) and logged in
(claude login / codex login — code mode reuses that saved credential).
- Chat path no longer auto-downloads: getProvisionedEnginePath() returns the
enabled engine or throws a clear "enable it in Settings → Code Mode" error, so
there's never a surprise mid-conversation download. getAgentLaunchSpec is sync
again.
- Agent status: `installed` now means "engine provisioned" (downloaded), driving
the Enable/Ready state; the new-session dialog shows "Enable in Settings" and
disables un-enabled agents. Dropped the dead PATH-probing for a global CLI.
Verified: empty cache -> status installed=false and the chat path throws the
enable-in-Settings error (no download); core, renderer, and main typecheck/build;
no new lint errors.
* fix(code-mode): show only percentage during engine download in Settings
* feat(code-mode): prune superseded engine versions after install
After a successful provision, remove any other version dirs (and their .meta) for
that agent so old ~200 MB engines don't accumulate across version bumps. Best-effort;
never fails a good install. Verified: a planted stale version dir + meta are both
removed after provisioning the current version.
* fix(code-mode): keep showing engine download % after reopening Settings
Provisioning state lived in the row component, which unmounts when the Settings
dialog closes — so reopening mid-download showed the Enable button again even though
the download was still running in the main process. Move provisioning state to a
module-level store with one persistent listener on codeMode:engineProgress, so a row
remounting (dialog reopened) reflects the live % and resolves to Ready on completion.
* fix(code-mode): flip Enable row straight to Ready after install (no Enable flash)
On successful provision the in-flight flag was cleared before the async status
refresh completed, so the row briefly (or until reopen) showed the Enable button
again. Await the status refresh before clearing the flag so it transitions directly
to Ready.
* fix(code-mode): optimistically show Ready right after Enable completes
Awaiting the status refresh wasn't enough — setStatus re-renders the parent
separately from the row, leaving a window where the in-flight flag was cleared but
the status prop was stale, so the row flashed/stuck on the Enable button until
reopen. Track just-enabled agents in a module-level set and treat them as installed
immediately; loadStatus still syncs the real status in the background.
* fix(code-mode): graft login-shell PATH + add startup deadline
#1 (the gh/git "command not found" in packaged builds): GUI/Finder launches inherit
launchd's stripped PATH (/usr/bin:/bin:...), so tools the engine spawns — gh, git,
rg, bash — fail even though they work from a terminal (e.g. Homebrew's
/opt/homebrew/bin/gh). Probe the user's login-shell PATH and graft it onto the
engine's env before spawn (shell-env.ts; no-op on Windows / probe failure).
#2: add a 60s startup deadline (initialize / session create+load) so a wedged engine
fails with a clear, stderr-enriched error instead of an infinite "(pending...)".
Overridable via ROWBOAT_ACP_STARTUP_TIMEOUT_MS. Manager now disposes the client on
startup failure so the spawned adapter doesn't leak.
Verified: getAgentLaunchSpec's env.PATH now includes /opt/homebrew/bin (where gh
lives); core builds; no new lint errors.
* chore(code-mode): comment out signing/notarization for local builds
Revert to the explicit comment-out approach for osxSign/osxNotarize: uncomment them
(with APPLE_ID/APPLE_PASSWORD/APPLE_TEAM_ID) for a signed release build.
* chore(code-mode): keep signing/notarization active in committed config
The repo's forge.config ships with osxSign/osxNotarize enabled (release-ready).
Developers comment them out locally for unsigned test builds and don't commit that.
* chore: approve workspace build scripts so packaging runs non-interactively
The allowBuilds entries were left as "set this to true or false" placeholders, so
`pnpm install` / the pre-build deps check aborted with ERR_PNPM_IGNORED_BUILDS and
`npm run package` failed. Set them to true (and add node-pty, used by the code-mode
embedded terminal) so build scripts are approved and packaging works without a manual
`pnpm approve-builds`.
* fix(code-mode): ship ACP adapters in packaged builds
Code mode spawns the Claude/Codex ACP adapters as separate `node <entry>`
processes resolved at runtime, so each must exist as a real file on disk.
esbuild can't inline them (dynamic require.resolve + spawn target), and Forge's
`ignore: /node_modules/` rule strips the workspace node_modules — so packaged
builds threw `Cannot find module '@agentclientprotocol/claude-agent-acp'` and
code mode was broken in every release. Dev worked only because the pnpm symlink
was present.
Stage the two adapters and their full production dependency closure into
.package/acp/node_modules during generateAssets, reconstructing an npm-style
nested layout: nest on version conflict (claude and codex keep their own
@agentclientprotocol/sdk; the @openai/codex launcher keeps its platform binary)
and skip platform-optional deps not installed for the build OS, so each OS ships
its own native binary. Exempt .package from the node_modules ignore rule, and
make the adapter resolver check the staged location first, falling back to
node_modules in dev.
Resolve dependency directories by walking node_modules directly rather than
require.resolve(`${pkg}/package.json`): the latter throws for packages whose
`exports` map doesn't expose package.json (e.g. @anthropic-ai/claude-agent-sdk),
which would silently drop them and their subtrees from the staged closure.
* fix(code-mode): drive agents from local install, drop bundled engines
Skip the platform-native engine packages (~230 MB each) when staging the ACP adapters and point each adapter at the user's local claude/codex via CLAUDE_CODE_EXECUTABLE / CODEX_PATH, erroring clearly when neither is installed. The codex resolver mirrors claude's login-shell probe so nvm/fnm installs resolve on macOS/Linux. Shrinks each installer ~460 MB.
* fix(code-mode): surface agent startup failures instead of hanging forever
- 60s deadline on adapter initialize / session create+load: an engine that
launches but never completes the SDK handshake (e.g. an outdated local
CLI) now fails with the adapter's stderr attached instead of leaving the
turn (pending...) indefinitely; prompts themselves stay un-timed
- dispose the adapter client when startup fails so the spawned process
does not leak
- set DEBUG_CLAUDE_AGENT_SDK=1 so the SDK logs the exact spawn command and
claude's stderr to ~/.claude/debug/sdk-*.txt and startup errors point at
that file (engine stderr is otherwise discarded entirely)
- graft the user's login-shell PATH onto the adapter env on macOS/Linux:
GUI launches inherit launchd's stripped PATH, which breaks node-shebang
claude launchers (nvm/npm installs) and the engines' own subprocess spawns
* ci(code-mode): cross-platform smoke matrix + one-shot diagnose script
- x-code-mode-smoke.yml: on apps/x PRs, package the app on mac/linux/windows
and run acp-smoke.mjs, which asserts (1) adapters staged + native engines
stripped, (2) each staged adapter boots from the packaged app via the
packaged Electron binary and answers ACP initialize, (3) a fake engine that
launches but never responds is converted into a clear startup-timeout error
instead of hanging forever (the silent-hang class)
- diagnose-code-mode.sh: colleagues run one command and send one blob
(engine versions/paths/types, login-shell vs GUI PATH, auth presence,
stream-json probe, newest SDK debug log) — one round trip instead of five
- forge.config.cjs: only sign/notarize when APPLE_ID is set, so unsigned
local mac builds and the CI smoke matrix can package deterministically
- client.ts: startup timeout overridable via ROWBOAT_ACP_STARTUP_TIMEOUT_MS
(CI uses 10s; also an escape hatch for slow MCP-heavy setups)
Verified on Windows: all smoke checks pass, including the end-to-end
fake-hanging-engine timeout (fails in 10.0s with the stderr-enriched error).
* fix(ci): make smoke fake engines executable — codex-acp spawns CODEX_PATH directly on unix
A bare .js with no shebang/exec bit fails with EACCES and crashes the adapter
on mac/linux. Split into an exec-bit exit-0 fake for the handshake check and
the hanging fake for the timeout check.
* fix(code-mode): resolve claude/codex installed via version managers
commonInstallPaths only checked ~/.nvm/versions/node/<binary>, never
descending into nvm's versioned vX.Y.Z/bin subdirs, so an nvm-installed
codex/claude showed "not installed" in Settings and failed code-mode
chat with "CLI not found" on GUI launches (where the login-shell PATH
isn't inherited).
Enumerate each installed Node version's bin dir for nvm/fnm/asdf, and
add pnpm global (PNPM_HOME / platform default) and Claude Code's legacy
~/.claude/local install location. Shared by both the Settings status
check and the chat/tab binary resolvers, so it covers all code-mode
entry points.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* chore(code-mode): remove code-mode smoke test workflow and script
Only needed during cross-platform verification of the packaged code-mode
fix; drop the CI workflow and its acp-smoke.mjs helper now that it's done.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Custom Electron Forge maker that wraps makepkg to produce a
.pkg.tar.zst with /opt/<app>, /usr/bin wrapper, .desktop entry,
and hicolor icon. Only activates on Linux when makepkg is present,
so other platforms are unaffected.
Adds INotificationService with an Electron implementation, plus a deep-link
dispatcher (rowboat://) for routing notification clicks back into the app.
Notifications:
- New `notify-user` skill + builtin tool. Title, message, optional primary
link, optional secondary actions. Supports https:// (opens in browser) and
rowboat:// (opens in app) targets.
- ElectronNotificationService holds strong refs to active Notification
instances so click handlers survive GC (otherwise macOS click silently
no-ops).
- Calendar meeting notifier fires 1-min warnings with "take notes" /
"join + take notes" actions backed by deep links.
Deep links (rowboat://):
- forge.config.cjs declares the protocol; main.ts wires single-instance
lock, setAsDefaultProtocolClient, open-url (mac), second-instance (win/
linux), and first-launch argv extraction.
- New deeplink.ts dispatcher with dispatchUrl(url): main-handled actions
(rowboat://action?type=...) vs renderer navigation (rowboat://open?...)
via app:openUrl IPC. Includes pending-URL buffering for first-launch
delivery before the renderer is ready.
- Renderer parseDeepLink supports file / chat / graph / task /
suggested-topics targets.
- New app:consumePendingDeepLink IPC for renderer one-time drain on mount.
Refactor: extractConferenceLink moved out of calendar-block.tsx into
shared lib/calendar-event.ts (used by both the block and the take-notes
deep-link handler)
Native meeting transcription that captures mic and system audio, transcribes
live via Deepgram, and generates AI-powered meeting notes.
- Toggle button in toolbar to start/stop meeting transcription
- Dual-stream audio capture: mic (You) + system audio (They) via getDisplayMedia
loopback
- Multichannel Deepgram transcription with diarization for speaker
identification
- Headphone detection with mic gating when using speakers to prevent echo bleed
- Live transcript saved to knowledge/Meetings/rowboat/{date}/ as markdown
- Auto-stop after 2 minutes of silence
- LLM-generated meeting notes prepended above raw transcript on stop
- Calendar event matching: pulls nearby events from calendar_sync to identify
meeting title and participant names
- First-time permissions setup modal on macOS for Screen Recording
- Button only visible when Deepgram is available (logged in or API key
configured)
