Computers

A Computer is a connected device, server, or container where an Agent can run work. It provides the operating system, files, credentials, network access, and tools required by an Agent.

A connected Computer in Anakin

Computer, Runtime, and local service

These terms describe different parts of execution:

  • Computer: the connected host. A Computer can expose one or more Runtimes and has its own owner, visibility, status, and task concurrency limit.
  • Runtime: a supported Agent execution capability detected on a Computer. Each Runtime identifies a provider and reports its own connection state. An Agent needs a usable Runtime before it can run.
  • local service: the background process that runs on the Computer. It registers the Computer, detects Runtimes, sends heartbeats, receives queued runs, prepares directories, starts Agent tools, and reports progress and results.

The local service initiates the connection to the server, so a typical setup does not require an inbound port.

The Computer detail page's Runtime section also lists the development environments the local service detects on the Computer — tools installed on it such as Node.js, Python, uv, and bun, plus the built-in environments the local service maintains itself — each with its version and path. Check this list before sending an Agent to that Computer to confirm the toolchain a task needs is present.

Connect and register a Computer

When you use the Anakin desktop app to connect a new Computer, the CLI / local-service method is recommended and expanded by default. In the web app, the desktop-app method remains the recommended entry point. This changes the presentation order only; the platform-specific connection steps remain the same.

Create a one-time install token from the Computers page, then run the registration command on the target Computer:

anakin computer register --install-token <install-token>

Registration records the Computer in the selected organization and starts or restarts the local service unless the command is told not to. The local service then detects installed Runtimes and reports them with the Computer.

After registration, confirm that the Computer appears and that at least one supported Runtime is available. A connected Computer without a usable Runtime cannot execute Agent work.

If connecting a Computer is rate limited, the app waits and retries automatically. You can cancel the wait. This is not a local-service failure, so do not reset or repair the local service. If you cancel and try Connect again, you still need to wait until a retry is allowed. A registration command in the terminal that hits a long wait tells you to try again later instead of holding the terminal.

Install the desktop app on Linux

The Linux desktop app is currently available for x64 only: 64-bit systems with Intel or AMD processors. If you are not sure, run uname -m in a terminal: x86_64 means you can install it; ARM machines that print aarch64 or arm64 are not supported yet.

It comes in three package formats. Pick one.

PackageWorks onUpdates
AppImage (recommended)Mainstream Linux distributions, such as Ubuntu, Debian, Fedora, openSUSE, and ArchUpdates itself in the app
debDebian, Ubuntu, Linux Mint, Deepin, and other Debian-based distributionsDownload and install new versions manually
tar.gzSame as the AppImage; use it when you want to manage the install folder yourselfDownload new versions and replace the whole folder

AppImage: unzip the download and run the AppImage inside.

unzip Anakin-linux-x64-latest.zip
./Anakin-*.AppImage

The extracted AppImage is already executable, so you can also double-click it. If it says the file is not executable, run chmod +x Anakin-*.AppImage, or right-click the file → Properties → select Allow executing file as program. It needs no administrator rights and no extra system libraries.

deb: unzip the download, install it with apt, then open Anakin from the app list.

unzip Anakin-linux-x64-deb-latest.zip
sudo apt install ./Anakin-*.deb

If apt reports missing dependencies, run sudo apt update and install again. To uninstall, run sudo apt remove anakin.

tar.gz: extract it anywhere and start it with the anakin.sh inside.

tar -xzf Anakin-linux-x64-latest.tar.gz
cd Anakin-*/
./anakin.sh

Known limitations:

  • The tray icon needs a desktop with AppIndicator support. Ubuntu's desktop has it; stock GNOME needs the AppIndicator extension. Without a tray, open Anakin again from the app list after closing the window to bring it back.
  • Start the tar.gz with anakin.sh. Running the anakin binary inside it directly exits on distributions that restrict user namespaces (such as Ubuntu 23.10 and later) because the sandbox cannot start.
  • The AppImage does not add itself to the app list. To open the app from the app list or pin it to the dock, install the deb.
  • Uninstalling the deb keeps your data (~/.config/Anakin) and the Anakin CLI (~/.local/bin/anakin). If you chose to keep the local service running in the background, clear that option when quitting the app or run anakin daemon stop before you uninstall.

Runtime capability status

Computer detail reports a capability status for each Runtime:

StatusMeaning and next step
AvailableThe Runtime is connected and can execute Agent work.
OfflineThe Runtime or local service is temporarily disconnected; check the local service and network. This does not mean that the tool is uninstalled.
Not detectedThe required tool is not available to the local service. For a Runtime that has its own CLI, follow the detail page and install the CLI, not the desktop app; or choose another Runtime.
InstallingThe page is installing this Runtime for you. Re-detect after it finishes, and do not start the install again while it runs.
Detection failedRuntime detection returned an error; follow the detail-page guidance, then rescan or test the connection.

A Computer being online does not mean that a Runtime is online or executable. Runtime Offline means that the Runtime or local service is temporarily disconnected; it does not mean that the tool is uninstalled and is distinct from Not detected. The Computer's own Offline status is separate. When a Task cannot start, check the selected Runtime status and then the Computer connection.

When you create or configure an Agent, unavailable Computers or Runtimes in the list include View computer after you hover, so you can open the details. The picker lists Runtimes already available on that Computer; it does not mean those are the only supported Runtimes. Use More supported Runtimes to open Computer details and install other supported Runtimes.

Install a Runtime

When a Runtime shows Not detected, install the corresponding command-line program on that Computer before asking the local service to detect it again.

Some Runtimes support one-click install: press One-click install and the page runs the install command for you, so you do not have to copy it into a terminal. The Runtime shows Installing while it runs; re-detect when it finishes. A Runtime that cannot be installed this way keeps the button disabled, with a tooltip explaining a manual install is needed, and the page says so outright when this Computer is missing a prerequisite command every install method needs — install manually with the guide below in that case.

One-click install is offered on Computers you own: not just the Computer you are using — a remote Computer you own can also be installed from the page, with the install command executed by that Computer's local service. The entry is disabled or hidden with the reason when you are not the owner, the Computer is offline, or its local service has not confirmed support; organization or Space visibility does not grant install permission.

On the Computer you are using, a Runtime that is installed and shows Available also supports one-click upgrade: press One-click upgrade and the upgrade command runs in the background through this Computer's local service, bringing the Runtime up to its latest version. The button cannot be clicked again while an upgrade runs; Computer and Runtime information refreshes when it finishes, and both success and failure raise a notification. One-click upgrade is offered only on the Computer you are using, not on remote Computers. It upgrades the Runtime itself — it is not the same as Check for updates in desktop settings, which updates the Anakin client and local service (see "Updates, restart, and repair").

After you open the installation guide, some Runtimes explain that a desktop app, IDE extension, or remote Gateway can be usable without a detectable local command-line program. Follow that notice and the guide on the detail page. User-visible Runtime names follow the product UI.

If it shows Detection failed, follow the detail-page guidance and rescan or test the connection after correcting the configuration. An online Computer only confirms that the local service is sending heartbeats; it does not make every Runtime executable. If detection or chat reports that a Runtime is unsigned-in or unauthorized, run the command shown on the page in a terminal on that Computer. That login is separate from anakin login --token.

Test connection asks the Runtime to answer for real — one actual model inference — so it requires model credentials on that Runtime: freshly installed and not yet signed in, the test usually ends in a timeout, which is not a product fault. When the failure points to credentials or sign-in, the failure card shows that Runtime's login command (for example opencode auth login); complete the sign-in on the target Computer as guided and retry from the page.

The Computer detail page provides an Official installation guide link for every Runtime currently exposed by the Runtime selector and support matrix. The selector and vendor links can change, so use the link shown for the selected Runtime rather than relying on a fixed provider list or copying an unverified install command from this page.

After installing the tool, return to Computer detail and use the available rescan or connection-test action to confirm that the local service can see the Runtime. The exact button name, supported platform, and available Runtime set follow the product UI and current support matrix.

Configure a detected Runtime

A detected Runtime shows its Install Location on this computer — the copy the local service actually runs — so you can confirm which one starts. The location is reported only after the version probe succeeds; it is not shown when detection fails.

The Computer owner can configure the executable, default additional arguments, and default environment variables for a detected Runtime. The executable can replace the detected default location. These values provide startup defaults for Agents that use the Runtime; they do not create a custom ACP Runtime. A matching Agent-specific argument or environment variable takes precedence over the Runtime default.

When --model appears in the additional arguments, it only sets that Runtime's default model — it does not lock model selection: Runtime settings, Agents, and chats can still pick another model, a saved selection takes precedence, and per-use picks work; the pickers note that the default comes from the launch arguments.

Before saving an executable, Anakin checks that it is executable and compatible with the Runtime's provider and version. If that check fails, the existing configuration remains unchanged. After you enter and successfully save an executable path, the UI should show that manual path, not Auto-detected, and later auto-detection does not overwrite it. After changing a Runtime, use Test connection or rescan it to confirm that the local service can still start it. If the tool is uninstalled, rescan it so its status can update.

After you change an executable, the local service may briefly restart and recheck the configuration. Restarting and rechecking is an intermediate state, not a final failure. Do not submit conflicting recovery actions again while it is in progress. Wait for success, an explicit failure, or a timeout; treat it as an error only after an explicit failure, timeout, or failed recheck. After success, refresh the Computer, Machine, and Runtime information.

No Runtime is a Computer-level summary that the Computer is not currently reporting a Runtime to select. It is not the same as an individual Runtime state such as Not detected, Detection failed, or Available. Runtime Offline also does not mean Not detected. Whether or not the Computer is online, use the selected Runtime's check or connection test to establish that it can run.

Enter only the configuration the product asks for. Do not put passwords, tokens, API keys, private keys, or other sensitive values in the executable, additional arguments, or unrelated fields.

Set up models manually

When a Runtime has not successfully detected any model yet (detection failed, returned an empty list, or has not run), the model pickers in Runtime settings, Agent settings, and the chat composer offer Set up models manually at the bottom, opening the Runtime models dialog. Once a model is detected the entry disappears, but models added by hand stay.

Under Added by hand, enter a Model id the Runtime actually accepts — in the form <provider-id>/<model-id>, copied from the Runtime side rather than guessed from a display name. The field suggests ids from this Runtime's own installed files, and any id can be typed. A Display name and Effects tier (for example low, high) are optional.

Models added by hand merge with the detected ones in the model picker, deduplicated by exact id and badged Manual; re-detection, refreshes, and local-service restarts never overwrite or drop them, and removing a manual entry leaves the detected entry with the same id alone. Saving the list does not change the model currently selected for the Runtime, an Agent, or a chat — pick when you need it. An id the Runtime does not accept fails loudly at execution time; there is no silent fallback to another model.

The list is shared by this Computer · Runtime: members without management permission can view it, but only the Computer's owner can change it.

Configure a custom ACP Runtime

If the local service does not detect an execution capability, add a custom ACP Runtime from Computer detail:

  1. Configure the Runtime icon, name, and startup command.
  2. Save the Runtime and select Test connection.
  3. After it is configured, edit those values when needed or delete the custom Runtime when it is no longer used.

Enter only the configuration requested by the product. Do not place passwords, tokens, or other sensitive values in unrelated fields or startup commands.

ACP adapter isolation

When an ACP adapter lacks a compatible Node.js environment, Anakin first reuses an existing compatible environment. If one is not available, it can prepare a product-managed isolated execution environment for that adapter only. It does not modify the system-wide Node.js or npm, shell configuration, project directory, or the user's version-manager configuration.

If environment preparation fails, Anakin keeps the original environment and provides manual repair guidance instead of replacing the existing configuration.

On macOS, if Codex is not installed on its own, installing the ChatGPT desktop app is enough for the local service to register the app's bundled Codex CLI as a Runtime. Prefer a Codex you installed and put on PATH; the app bundle is only a fallback. This does not apply to Windows or Linux.

Computer commands

Use the anakin computer command group to inspect and manage registered Computers:

anakin computer list
anakin computer show <computer-id>
anakin computer usage <computer-id> <runtime-id>
anakin computer activity <computer-id> <runtime-id>
anakin computer ping <computer-id> <runtime-id>
anakin computer update <computer-id> <runtime-id>
  • list shows Computers registered for the current organization.
  • show returns the Computer and its Runtimes.
  • usage and activity inspect a specific Runtime.
  • ping checks whether a specific Runtime can complete a round trip through the local service.
  • update requests a CLI update for a specific Runtime.

Use --organization-id when the selected CLI organization is not the one you want to inspect.

Status and registration state

A Computer is Starting while the local service on this computer is starting or restarting. That is not Offline: the Computer and related entries should show the same starting state. A Runtime that is not detected, failed detection, or uninstalled keeps its own status and does not switch to Starting. In the web app, when this computer is not the local machine, the status dot in the lower left stays gray. An Agent conversation bound to this computer may say the Computer is starting and ask you to wait. After Restart service, the Computer enters Starting; a successful restart shows Restart successful.

A Computer is Upgrading while the desktop app is updating the local service. That is not Offline and not a failure. After the upgrade finishes, the Computer comes back Online without another Start. If you stop it during or after the upgrade, it stays Stopped. If the upgrade fails, follow the in-app prompt and try Start again.

A Computer is Online when the server is receiving current heartbeats from its local service. It is Offline when those heartbeats stop.

A Runtime also reports whether it is online or offline. These states are related but not interchangeable: a Computer can be online while no supported Runtime is available, and an Agent cannot run until its selected Runtime is usable.

During first-time setup, the desktop app can also show transitional states such as starting the local service, waiting for registration, or reconnect required. Registration is complete only when the server has accepted the connection and the Computer appears in the organization.

Updates, restart, and repair

In desktop settings you can Check for updates. When a newer version is found in the background, the update finishes automatically and does not pop up a new-version toast. That prompt appears only when you check for updates yourself.

Computer detail can also prompt you to:

  • Restart update: a new version is already downloaded on this computer, but the app still needs a restart to finish the upgrade.
  • Update now: the CLI on a remote Computer is out of date. Choose Update now, or run the command shown on the page on that Computer.

If the lower-left entry shows an unregistered This computer (local), open it and use Repair and reconnect. If the local service fails to start, the product shows repair steps and a command you can copy. If a community channel is configured, you can still contact it from there. Copy follows the product UI.

When the local service fails to start, the repair dialog explains what went wrong, offers One-click repair and Repair from terminal, and lists the original error so you can troubleshoot it. If the status shown in the UI and the actual connectivity disagree, for example a Runtime shown as available while the product asks you to repair the local service, trust the result of Test connection or a rescan.

Occupied local service on desktop

If Start on this computer is blocked because the local service is occupied:

  • occupancy from this product recovers in the app, without sending you to a terminal;
  • occupancy from another program shows the process name and how long it has been running, and you must confirm before ending it and starting;
  • if the occupier cannot be identified, Anakin explains why and does not end an unknown process.

If Start fails, try Start again. When an older or leftover local service remains, follow the in-app prompt and retry.

If in-app repair such as Reset and start or Retry Start fails outright, the primary action becomes Repair and reconnect, which can open the existing terminal reconnect steps. The original repair actions remain available. Not every failure automatically opens the reconnect guide.

Startup method

Computer settings include a Startup method:

  • Start at login: start the local service after you sign in to the system.
  • Start when app opens: opening the desktop app starts the local service.
  • Manual start: you start or stop it from the UI or CLI; do not expect opening the desktop app to start it.

When Start when app opens is selected, the description is: starts when the app opens. Quitting the app does not stop the local service by default; whether it stops is decided by Keep the Anakin CLI daemon running in the background, described in Quitting the app. If changing the startup method fails, the previous method stays in effect.

After you stop the service from the CLI or the UI, the desktop app does not immediately start it again during that session because it looks like an unexpected disconnect. After you fully quit and open the app again, the current startup method decides whether it starts.

Quitting the app

Closing the main window only hides the app by default, and the local service keeps running. What closing the window does is set by the close behavior under Desktop in settings: Minimize to tray (keep the app running in the tray when you close the window) or Exit app (fully quit the desktop app when you close the main window). macOS, Windows, and Linux behave the same. On a Linux desktop that shows no tray icon, open Anakin again from the app list after closing the window to bring it back; see Install the desktop app on Linux.

Quitting the desktop app explicitly (from the app or tray menu, or when the close behavior is Exit app) shows a confirmation window first:

  • Keep the Anakin CLI daemon running in the background is checked by default (if you turned this switch off before, the window opens with it unchecked), so the Computer stays online and Agents can continue receiving and running tasks;
  • Unchecking it stops the daemon, and warns that all Agents on this Computer will go offline and that running Agent tasks will be terminated;
  • When the daemon is actually being stopped, the app shows Stopping Anakin CLI daemon and Stopping the background service before it closes. If the stop cannot be confirmed, you can retry or exit without waiting.

The Keep the Anakin CLI daemon running in the background switch in Computer settings and the checkbox in that confirmation window are the same setting, so changing one is reflected in the other. It also decides whether Start when app opens stops the service at quit time.

System shutdown and sign-out, and the desktop app's own Restart update, do not show this confirmation.

Restart service and Stop service

Computer detail can Restart service or Stop service for the local service:

  • Restart service restarts the local service. Runtimes and Agents on this Computer go offline briefly. A manual restart runs immediately and does not wait for running tasks; only an automatic restart during task execution may wait.
  • Stop service stops the local service. After you stop it, Runtimes and Agents on this Computer stay offline.

This is separate from Start in the web app. After you stop the service, start it again before expecting the Computer to come back online.

If a Computer is offline or registration stalls, check that:

  • the target Computer is powered on and connected to the network;
  • the local service is running and authenticated;
  • the CLI is current enough to connect;
  • the selected Runtime is installed and available to the local service;
  • required repositories, credentials, directories, and commands are accessible on that Computer.

When connection, Start, or Runtime detection is stuck, the page can offer Help to open the docs. If a community channel is configured, it also offers a way to contact the Anakin community.

Prevent sleep

Prevent sleep appears only on this computer in the desktop app. It is not available on a shared or remote Computer.

When it is on, the machine stays awake while the display can still sleep under the system settings. This is not keep-display-on. Use it so local tasks and Agent connections are not interrupted by system sleep.

Duration options:

  • Always
  • 5 minutes
  • 30 minutes
  • 1 hour
  • 2 hours
  • 5 hours
  • 8 hours

The setting turns off when the duration ends. Changing the duration restarts the timer. Always does not expire.

Keep running with lid closed is a separate option. It appears only on macOS, and only when the system allows it. If the machine is unplugged, the product asks you to connect power first — do not treat the option as already in effect.

System load protection

A Computer's machine settings include a System load protection switch and a Protection policy, which keep a busy Computer from taking on new tasks. The switch is off by default.

When it is on and the system load average is too high, the Computer pauses taking new tasks: queued tasks show "System load average on the Computer is too high" and start automatically once the load drops. The policy never locks the Computer down completely — at least 1 task is still guaranteed to run above the limit.

The Protection policy can be set to a preset that fits how the Computer is used:

  • Smooth priority: prioritizes responsive daily work and coding with extra CPU headroom;
  • Balanced (Recommended): balances daily coding/builds with concurrent task execution;
  • Full capacity: best when the computer is idle or dedicated to running tasks at full speed;
  • Manual: set the 1-minute load average limit yourself (a whole number between 1 and 1000).

Visibility and ownership

Visibility controls who can see and use a Computer in an organization:

  • Personal: available to the owner.
  • Organization: available across the organization.
  • Space: available through the selected Spaces.

Ownership is separate from visibility. The owner controls the Computer itself, can transfer ownership to another person in the organization, and is the only person who can delete it. Organization or Space administrators may be able to repair shared access settings without becoming the owner.

The owner can also Unbind runtime for one Agent, or Unbind all, from the Agents area on the Computer detail page. This is how the owner reclaims the Computer without deleting it:

  • The Agent stays; it is not archived or deleted. This Computer is cleared as its execution target, so it must choose a Computer again before it can run.
  • Active runs are cancelled. Assigned tasks need reassignment.
  • Unbinding does not grant full edit access to someone else's Agent.

Confirmation copy follows the product UI. Deleting a Computer can still be blocked while an active Agent is bound; unbind first, then delete.

Use Personal visibility for a personal device or private credentials. Use Organization or Space visibility only when the host and its credentials are intended for shared Agent work. For the full guidance — including why not to publish the Agent that lives on your daily machine, and how to prepare a virtual machine, container, or shared host for shared execution — see Using Agents and Computers securely.

Allowed Organizations

The owner of a local personal Computer can also control which Organizations may use it:

  • All Organizations allows Organizations where the owner is currently a member, including Organizations the owner joins later.
  • Selected Organizations allows only Organizations explicitly selected for the Computer.

Only the Computer owner can change this setting. Being an Organization Owner or Admin does not grant control of another person's personal Computer.

Visibility and allowed Organizations are separate restrictions: visibility determines who can see or select the Computer within an Organization, while allowed Organizations determines where that local personal Computer can be used.

If this Computer is already connected in one Organization, switching to another Organization that is not allowed should say the Computer is not allowed in the current Organization, and offer Set allowed organizations. Do not treat this as Starting, waiting to sync, or a missing Runtime, and do not use Repair and reconnect or install-and-register as the main path. The setting entry opens this Computer's details in an allowed Organization and focuses allowed Organizations. Add the current Organization, save, then return to that Organization to use it. After you transfer ownership, allowed Organizations may include only the new owner's current Organization; switching to another Organization uses the same prompt.

Network proxy

A Computer's detail page can configure a network proxy for the CLI / local service and Runtimes on that machine to reach the network. It is the same data as the proxy configuration in the CLI and the desktop app's settings dialog (kept in this machine's config directory) — a change in any of these entry points syncs to the others.

There are four proxy modes:

  • Follow local desktop proxy (the default; offered only for this computer when the desktop app is installed): inherits the desktop app's network-proxy settings and shows live which mode it currently follows;
  • Use system proxy: reads the system proxy automatically. On Linux desktops it detects GNOME (gsettings), then KDE (kioslaverc), then /etc/environment, in that order. You can switch on Prefer HTTP_PROXY, HTTPS_PROXY, NO_PROXY system environment variables to keep the proxy variables the process already has, or clear them and use only the system settings; for intranet system proxies that hand out only a host:port, you can also enable Authentication on top of the system proxy to supply a username and password;
  • No proxy: the local service and Runtimes on this Computer bypass any proxy;
  • Custom: enter a proxy server address and port (SOCKS5 supported), toggle HTTP / HTTPS independently so only the chosen protocols go through the proxy (at least one stays on), and set a comma-separated Proxy Bypass list of IPs or domains; proxies that require a login can enable Authentication with a username and password.

Remote Computers and pure-CLI environments cannot change proxy settings online yet — the dropdown shows "-". Saved proxy authentication and a custom SOCKS5 proxy apply to this Computer's local Agent tasks when they reach the network.

Concurrency and working directory

A Computer can serve several Agents. Tasks may queue when the Computer is offline, the selected Runtime is unavailable, Computer or Agent concurrency is full, a specified in-place directory is busy, repositories, credentials, or required commands are unavailable, or System load protection is on and the load average is above the policy limit (tasks start automatically once load drops).

If the Agent uses Create temporary directory, or Specified with Run in isolated worktrees, tasks typically run in separate Git worktrees and do not write to the same working tree. Isolated mode supports one directory.

If the Agent uses Specified with Run directly in this folder, one directory usually serves one run at a time. When no directory is free, the run waits for a local directory.

Default concurrency:

  • Specified directories running in place: default concurrency matches the number of configured directories.
  • Create temporary directory, or Specified with isolated worktrees: default concurrency is 50% of the Computer limit.

Higher concurrency uses more CPU, memory, disk, and network. Working-directory modes and run states are covered in Agent task execution.

Disk usage and automatic cleanup

Agent runs leave working directories, caches, and artifacts on the Computer. Configure automatic cleanup in the desktop local-service settings or Computer cleanup settings.

The settings include:

  • Cleanup frequency (hours)
  • Terminal run retention (days)
  • Minimum free space (GiB, 0 disables)
  • Additional repository cache retention after eligibility (days)

The default is active: terminal runs such as completed or canceled work become eligible after about 7 days. You can also set a minimum free-space threshold (conservative default 10 GiB; 0 turns it off). When free space is below the threshold, cleanup only reclaims the same safe set, preferring larger items.

Regenerable directory names such as node_modules, .next, dist, build, and target are candidates, not deletion permission by themselves. The local service removes a candidate only when Git confirms that the repository ignores it and the directory contains no tracked files. State directories such as .task-env remain protected even when a repository ignores them.

Automatic cleanup does not remove:

  • running or queued work;
  • pinned runs;
  • failed runs that still need investigation;
  • nested Agent caches such as ~/.claude/worktrees.

Restart the local service or re-register the Computer after saving. Do not delete local-service directories you do not understand.

For an immediate check or a one-off cleanup, use the CLI:

anakin daemon disk-usage
anakin daemon cleanup
anakin daemon cleanup --confirm

daemon cleanup is a dry run unless --confirm is present. The desktop policy and the CLI commands complement each other; neither replaces the other.

Remove a Computer

Deleting a Computer removes its registration and attached Runtimes. Deletion is blocked while an active Agent is still bound to one of those Runtimes. Reassign or archive those Agents first, then delete the Computer as its owner.

Desktop GPU troubleshooting

When running live wallpaper tools (such as Wallpaper Engine), screen-capture overlays, or unstable graphics drivers on Windows, the desktop app can experience window flickering, blank frames, or black screens due to DWM DirectComposition / MPO hardware overlay contention or GPU process crashes.

On Windows, the desktop app disables DirectComposition and hardware video overlays (disable-direct-composition, disable-direct-composition-video-overlays) by default to prevent most live-wallpaper flickering, and automatically falls back to software rendering if the GPU process fails to launch or crashes repeatedly. If flickering or black screens still occur on your machine, you can disable hardware acceleration using any of the following methods:

  1. Pass a startup flag on the desktop shortcut or command line (Recommended):

    • Windows desktop shortcut: Right-click the Anakin shortcut → Properties → Shortcut, and append a space followed by --disable-gpu (or --disable-hardware-acceleration) to the end of Target:
      "C:\Users\<username>\AppData\Local\Programs\Anakin\Anakin.exe" --disable-gpu
      Save the shortcut, fully quit Anakin, and launch it again from the shortcut.
    • macOS / Linux terminal: Fully quit the app and launch the binary with --disable-gpu (for example Anakin --disable-gpu).
  2. Persist the setting in a configuration file (applies when launching from icons or login items): Create or edit gpu-preferences.json (or VS Code-style argv.json) in the desktop user data directory:

    • Windows: %APPDATA%\Anakin\gpu-preferences.json
    • macOS: ~/Library/Application Support/Anakin/gpu-preferences.json
    • Linux: ~/.config/Anakin/gpu-preferences.json

    Write the following JSON and restart the desktop app:

    {
      "disableHardwareAcceleration": true
    }
  3. Automatic fallback and re-enabling hardware acceleration: If the GPU process fails on launch (launch-failed), the desktop app automatically writes "disableHardwareAcceleration": true to gpu-preferences.json and immediately relaunches in software rendering mode; if the GPU process exits abnormally twice within 60 seconds (crashed, oom, killed, or abnormal-exit), it persists "disableHardwareAcceleration": true to gpu-preferences.json so the next launch starts in software rendering mode. After updating your graphics driver, you can re-enable hardware acceleration by launching once with --enable-hardware-acceleration, or by setting "disableHardwareAcceleration": false in gpu-preferences.json (or deleting the file) and restarting.