Background service
Keep running when closed - your computer stays reachable from your phone and the web after you quit Foxl - plus Keep this computer awake, and what quitting stops
Foxl is described as a 24/7 agent, but until you turn this on the local server and the relay connection both belong to the app - so quitting it takes the machine offline. On Linux with the tray icon off, closing the window quits Foxl, so there it does too.
Settings > General > Keep running when closed moves both into a small background service that the operating system owns. The app then attaches to that service when you open it, and quitting changes nothing.
Off by default, and turning it off puts everything back the way it was. The switch only appears on the desktop app, and only on a platform that supports it - an older build or an unsupported system shows no switch at all rather than one that cannot work.
What gets installed
| Platform | Mechanism |
|---|---|
| macOS | A launchd user agent |
| Linux | A systemd user unit |
| Windows | A Task Scheduler task that runs at sign-in |
Nothing needs administrator or root: it is a per-user service, installed and removed by the switch.
On macOS it appears in System Settings > Login Items as Foxl, with the Foxl icon. Machines that had the setting on before that was true are corrected on the next launch - there is nothing to switch off and on again.
The service file is rewritten on every launch of the app, so anything you edit
into it by hand - an environment variable, a path - is undone the next time Foxl
opens. Settings that need to reach the service have their own switches in the app.
The file hardcodes the path to the installed app, so if you move Foxl the service
exits with status 78 rather than looping; opening the installed app once rewrites
the file to the new location. Its own state lives in ~/.foxl/daemon.json,
readable only by your user - it holds the relay refresh token the service signs in with to
reach your phone and the local connection token that guards the server on your
machine.
Turning it on or off restarts Foxl
Both directions restart the app, and the restart is the point rather than a side effect: ownership of the server and of the phone connection moves between two processes, and several things are decided once at launch from which process owns them.
Foxl waits for the handover, says it is restarting, and comes back attached. If the restart stalls it is forced through, because a half-converted app is worse than either state - after turning the setting off, a stay-behind app would serve locally with no relay connection at all, so your phone could not reach the machine until some later launch.
While it is running
- The app no longer starts a second server of its own. The two would fight over the same port.
- The Restart button asks the service to restart rather than killing it.
- A Restart service link sits on the status line under the switch, for the case where the service is running but its server is wedged. It reports the outcome rather than just firing off the request.
- The status line distinguishes "the service is running", "the service is running and signed in" - reaching this computer from your phone needs an account, so a signed-out service says so - and "the service is missing from this system", the one state where Restart service reinstalls rather than restarts.
- If the operating system has lost the service - the file is on disk but its manager no longer knows it - every launch of the app checks for that case and repairs it, and Restart service reinstalls it instead of restarting nothing.
- If the service genuinely cannot be started, Foxl turns the setting off itself, runs the server inside the app so the window still opens, and says so under the switch: "Foxl could not start the background service, so this app is running the server itself. Turn this back on to try again."
- If another program is using Foxl's local port (13847), the service does not keep restarting: it waits for the port and starts its server within about 30 seconds of the port coming free, and Foxl's startup screen says the port is used by another program.
The local port at startup
Foxl's local server listens on port 13847. When something already holds it as Foxl starts:
- A Foxl server left over from an earlier run - for example after the app was force quit - is stopped without a question, and Foxl opens in a few seconds.
- On Windows, another program gets one question, naming it:
Port 13847 is in use by <program>. Quit it so Foxl can start?Only Quit closes it, and only that program, leaving anything it started running. Cancel closes nothing.
When you quit Foxl
On a Mac and on Linux, quitting Foxl - or force quitting it, or a crash of the app - stops its local server, and what the server started stops with it, even when the server itself is killed outright: MCP servers, hooks, the Signal channel's receiver, the on-device engines and their installs, the ChatGPT sign-in, and any command the agent left running in the background, such as a dev server it started.
Keep running when closed is the exception, on purpose: it keeps the server, and what it started, running after you quit the app.
Keep this computer awake
Settings > General > Keep this computer awake stops the computer from going to sleep on its own for as long as Foxl is running, not only while a reply or a run is in progress, so a long run is not cut off halfway and the next scheduled run finds the computer awake. It is off by default.
- With Keep running when closed on, it keeps working after you quit the app. On Linux the background service then asks systemd-logind to hold off idle sleep, and whether your desktop's own power settings follow that request depends on the desktop. If the service cannot keep the computer awake, Settings says so under the switch.
- The screen still turns off to save power, and closing the lid or choosing Sleep still sleeps the computer. It does not wake a computer that is already asleep.
- On battery it uses more charge.
It picks up updates on its own
The service is a plain background process, so it has no updater of its own. It watches its own bytes instead: when the build on disk is no longer the one it is running, it stands down and the operating system starts it again on the new build, within about two minutes.
| Platform | What is replaced |
|---|---|
| macOS, Linux | The whole service replaces itself. |
| Windows | The part that serves your phone is replaced immediately; the rest is updated the next time you open the app. |
It comes back if something kills it
Anything that stops the service without turning the setting off - a crash, a kill from a task manager - would leave the machine unreachable with the switch still reading as on, so the service tells the system it wants to be restarted in that case:
- macOS, Linux - back within about ten seconds.
- Windows - the task also re-fires every minute while you are signed in, so a crashed service is back within a minute (about 30 seconds when measured).
A stop you actually asked for - turning the setting off, or an app update replacing the service - still stops cleanly.
Limits worth knowing
The service runs headless, so two things still need the app open:
- Desktop notifications. A question from Foxl Code still reaches you through your phone and the in-app panel as usual.
- App auto-update. The service updates itself as described above; the app bundle is replaced by the app's own updater.
On Linux the installer also asks the system to keep your user services alive after logout. If that prompt is declined, Foxl says so and the service runs until you log out.
Logs
One append-only file per day at:
~/.foxl/logs/daemon-<date>.logFiles older than 14 days are deleted. A 24/7 process needs a retention cap; the app's own per-session logs are not pruned the same way.
Related
- Desktop relay - how the phone and web app reach this computer at all.
- Mobile Apps - what a phone can and cannot do while your desktop is unreachable.
- Troubleshooting