Skip to main content
The daemon runs GitHub and Slack tasks in the background on a machine you choose. Prepare that machine with the project’s build tools, repository access, and any required lab equipment.

Start

Complete the authentication prompt if one appears. Once the command reports that the daemon has started, you can close the terminal. For an unattended host, provide an API key issued for your Embedder account in the host environment:
Keep the key out of repository files and task messages. If authentication is rejected, check that the key is valid for the intended account before retrying.

Restrict work to one project

By default, the daemon can run work for accessible mapped repositories. To select one project, provide both team and project names:
Use exact names and quote spaces. EMBEDDER_TEAM and EMBEDDER_PROJECT provide the same selection through environment variables; always set them together. The directory where you start the daemon is not the task’s checkout. Each task uses its mapped repository.

Monitor work

Check connection status, active GitHub and Slack tasks, selected project and model, and work waiting for hardware. Use arrow keys or j and k to scroll. Press m to change the model when one daemon is listed. Press q, Escape, or Ctrl+C to close the monitor while leaving the daemon running.

Set parallel capacity

To allow more independent tasks at once:
The default is four. Choose a value the host can support. Tasks targeting the same pull request or conversation wait for one another, and increasing capacity does not let multiple tasks drive the same board simultaneously.

Keep runs within the time limit

A daemon run has a 30-minute time limit. Time spent waiting in Embedder’s hardware queue can extend the deadline by the amount waited, up to 20 additional minutes. The run stops if it exceeds that deadline. Split long builds, investigations, or soak tests into requests that can finish within the limit. If a run reports a duration-ceiling error, inspect its partial result and narrow the next request before retrying.

Stop

If more than one daemon is listed, select the PID shown in the monitor:
You can also use the monitor’s Stop control. Check active work before stopping the host.
Tasks run with automatic approvals and can edit, build, and use available hardware. Limit the host account to the access intended for automation, and state hardware restrictions in each request.

Troubleshoot

  • Connected but idle: check the repository mapping and both project-selection flags.
  • Waiting for capacity: let an active task finish or reduce simultaneous work on the host.
  • Waiting for hardware: find the active hardware task before stopping or releasing it.
  • No daemon in the monitor: run the commands under the same operating-system account and configuration used to start it.
  • A task failed: read the result in GitHub or Slack, fix the reported setup issue, and request a new run.
  • Duration limit exceeded: shorten the request or split it into separate build, test, and investigation steps.
Last modified on September 12, 2026