Problem
BYO Agent currently reuses the First Tree daemon. The BYO Agent itself does not install an additional startup service—its integration is activated through Coding Runtime plugins—but using BYO can still require the daemon to be installed and enabled as an OS login/boot service.
That behavior does not match a project-scoped BYO mental model:
- opt in for a specific project;
- start or load the required integration only when that project is used;
- avoid an always-on background service when no BYO project is active.
An always-running daemon can consume PC resources and makes BYO feel like another system-wide startup dependency rather than a project-local capability.
This is a backlog request, not a request for immediate implementation. The current daemon architecture may make this a substantial change.
Desired behavior
Provide a BYO-only operating mode that does not require the First Tree daemon to auto-start at login or boot. The relevant Coding Runtime plugin/session should activate the minimum required local functionality on demand for an opted-in project.
Users who rely on the full First Tree daemon should be able to keep the existing background-service behavior; background startup should be explicit for BYO-only users rather than an implicit consequence of setup.
Acceptance criteria
- Setting up BYO Agent alone does not install or enable a login/boot startup entry by default.
- BYO activation remains opt-in and project-scoped.
- Opening a supported Coding Runtime session for an enabled project starts or connects to the required local functionality on demand.
- When no enabled project needs it, BYO Agent does not require a permanently running background daemon.
- Existing managed/full First Tree daemon workflows continue to support explicit background startup.
- Setup, status, and documentation clearly distinguish on-demand BYO mode from the always-on daemon mode.
- Behavior is defined consistently across supported desktop service managers.
Implementation note
This issue tracks the product behavior rather than prescribing whether the solution should be daemon decoupling, lazy daemon activation, a lightweight project-local process, or another architecture.
Related
Problem
BYO Agent currently reuses the First Tree daemon. The BYO Agent itself does not install an additional startup service—its integration is activated through Coding Runtime plugins—but using BYO can still require the daemon to be installed and enabled as an OS login/boot service.
That behavior does not match a project-scoped BYO mental model:
An always-running daemon can consume PC resources and makes BYO feel like another system-wide startup dependency rather than a project-local capability.
This is a backlog request, not a request for immediate implementation. The current daemon architecture may make this a substantial change.
Desired behavior
Provide a BYO-only operating mode that does not require the First Tree daemon to auto-start at login or boot. The relevant Coding Runtime plugin/session should activate the minimum required local functionality on demand for an opted-in project.
Users who rely on the full First Tree daemon should be able to keep the existing background-service behavior; background startup should be explicit for BYO-only users rather than an implicit consequence of setup.
Acceptance criteria
Implementation note
This issue tracks the product behavior rather than prescribing whether the solution should be daemon decoupling, lazy daemon activation, a lightweight project-local process, or another architecture.
Related