Repository navigation
Desktop tools unavailable when a source CLI starts a worker in an installed app's data directory #128
Description
Activity
Reproduced from Ace Canary channel
team-agent-access(974cbd24fb896875) during a reserved native UI slot, with a different message than the original report:desktop_apps → Native desktop tools require the Ace desktop app on this host. Source hosts can set ACE_DESKTOP_CLIENT to its bundled ace-desktop-client.Ace Canary was open (
/Applications/Ace Canary.app, Ace Helper pid running),~/.local/state/ace-canary/desktop.sockexisted, andAce Canary.app/Contents/MacOS/ace-desktop-clientwas present.Cause observed: the channel's worker was not started by Ace Helper.
~/.local/state/ace-canary/logs/cli.jsonl:21:12:38.558Z cli.command pid 59824 command ask ref team-agent-access 21:12:38.571Z worker.spawn proc cli pid 59833 channel 974cbd24fb896875A source-checkout
bun ace ask(withACE_HOMEpointing at Canary's data) found the channel dormant and spawned its worker as~/.bun/bin/bun --no-env-file /Users/natebutler/code/ace2/apps/host/src/worker.ts 974cbd24fb896875.native()inapps/host/src/desktop.tsresolves the client fromACE_DESKTOP_CLIENTor besideprocess.execPath, which is~/.bun/bin/bunhere, so every desktop tool fails before reaching the socket. At the time, all running Canary workers for channels coordinated this way had the same provenance (7worker.spawnlines fromproc: cli).Reproduce: with Ace Canary open and the channel dormant, run
ACE_HOME=~/.local/state/ace-canary bun ace ask <channel> …from a source checkout, then invoke anydesktop_*tool in that channel.Possible directions (not implemented): have a CLI-started worker locate the installed app's client for that data directory, refuse or warn when a source CLI starts an installed app's channel worker, or report the worker's provenance in the error. Workaround: let the worker retire and reopen the channel from Ace so Ace Helper starts it, or start the source CLI with
ACE_DESKTOP_CLIENTset to the bundled client.This blocked native owner UI verification for the collaborator-agent sharing work (dogfooding #5).
Reproduced again from Canary channel
channel-watch-recovery(26338e726ba05a2d).desktop_appsreturned the ACE_DESKTOP_CLIENT error while Ace Canary was open; the worker was~/.bun/bin/bun --no-env-file /Users/natebutler/code/ace2/apps/host/src/worker.ts 26338e726ba05a2d, started from a source CLI. This blocked native UI validation for #159 (#153). Dogfooding #5.- changed the title
[-]Desktop tools unavailable from a Canary channel while Ace Canary is open[/-][+]Desktop tools unavailable when a source CLI starts a worker in an installed app's data directory[/+]on Oct 6, 2026 - added a parent issue
on Oct 6, 2026
While building the details sidebar (channel sidebar-populate), every native desktop tool call (
desktop_apps, with and without a query) failed with "Open Ace on this host to enable native desktop tools." even though Ace Canary was running and hosting the channel. A lane'sbun run devAce-dev app was also running.Without them the agent could not inspect or click the Ace-dev window to smoke-test UI, and fell back to driving the dev host's web app with Playwright's cached Chromium outside Ace. The agent's
readtool also cannot show the resulting PNG screenshots, so visual checks were limited to DOM text.Expected: desktop tools work from a channel whenever its host's Ace app is open, or the error says what is actually missing.
Cause and scope (updated Oct 6)
The reproduced cause is worker provenance (details): a source-checkout
bun aceCLI using Canary's data directory (ACE_HOME) started the dormant channel's worker itself. Without explicitACE_DESKTOP_CLIENT,native()inapps/host/src/desktop.tslooks for the client besideprocess.execPath, which for that worker is Bun, so every desktop tool fails before reaching Canary's socket. #118 fixed the supportedbun desktop devrunner, which passes its checkout's client explicitly; it doesn't cover a source CLI starting a worker in an installed app's data directory.Expected now: such a worker finds the installed app's client, or the CLI refuses or warns before starting it, or the error names the worker's provenance. Reading saved screenshots is #51.