#2294 swamp serve daemon enable generates a systemd unit with no HOME/SWAMP_HOME, silently disabling extension loading

swamp serve daemon enable generates a systemd unit that sets neither HOME nor SWAMP_HOME. Extension loading is therefore disabled in the daemon, and every scheduled workflow that touches a repo-local extension fails with Unknown model type, while the identical workflow passes when run from the CLI.

The contradiction is inside swamp: the daemon installer omits the variable that swamp's own warning says is required when running under a service manager.

Environment

• swamp 20260918.211634.0-sha.bcaa9695, linux-x86_64
• Debian 13 on Proxmox VE, systemd
• Repo at /root/swamp with a repo-local extension in extensions/models/

Reproduce

1. swamp repo init in a repo with a local extension under extensions/models/.
2. Create a model of that type and a workflow with a trigger.schedule.
3. swamp serve daemon enable --host 127.0.0.1 --port 9090
4. Wait for the schedule to fire.

Observed at the scheduled time:

system │ Scheduled workflow "estate-offsite" failed: "Unknown model type: @local/estate-offsite"
system │ Scheduled run failed for workflow "estate-offsite": "Unknown model type: @local/estate-offsite"

The same workflow run from the CLI in the same repo succeeds, because the CLI inherits HOME.

swamp model type search disagrees with itself depending on which side is asked:

swamp model type search estate --json
  → @local/estate-offsite

swamp model type search estate --server http://127.0.0.1:9090 --json
  → results: []   hint: "No local types matched."

Cause, per swamp's own warning

At daemon startup:

[WRN] swamp·cli: 'Extension loading is unavailable: no swamp data directory found
(none of SWAMP_HOME, HOME, or USERPROFILE is set). swamp loads all extensions —
including already-pulled repo extensions — through an embedded runtime under the
swamp data directory. If you run swamp under a service manager such as systemd,
set SWAMP_HOME to an isolated directory, e.g. `Environment=SWAMP_HOME=/opt/swamp`,
or set HOME. Until then, pulled and user extensions are unavailable and workflows
that reference them fail with "Unknown model type".'

The generated unit is:

ExecStart="/usr/local/bin/swamp" serve --repo-dir "/root/swamp" --port 9090 --host "127.0.0.1"
WorkingDirectory=/root/swamp

No Environment= line at all.

Workaround

# /etc/systemd/system/swamp-serve.service.d/10-home.conf
[Service]
Environment=HOME=/root

Why this is worth more than the missing line

It fails silently and healthily. systemctl is-active reports active, /ready serves 200, swamp serve daemon status reports running, and the scheduler logs Scheduled execution service started with 1 schedules. Nothing surfaces that every one of those schedules will fail. The only signal is one [WRN] line at startup, and the failure then appears hours later as a per-run error that reads like a repo problem rather than a service-configuration one.

Suggested fixes, in preference order:

1. daemon enable writes Environment=HOME=… (or SWAMP_HOME=…) into the generated unit, since it already knows the repo directory and the invoking user.
2. Failing that, daemon enable refuses to install a unit that would start with extension loading disabled, and says so at install time rather than at first scheduled run.
3. Failing both, promote the startup [WRN] to a readiness failure, so /ready does not serve 200 while no local extension can load.