@edspencer/paddock 0.67.0 → 0.68.1

package/packages/server/dist/cli/paddock.js

@@ -23,10 +23,19 @@ import os from "node:os";
 import path from "node:path";
 import { spawn } from "node:child_process";
 import { fileURLToPath } from "node:url";
-import { HERE_MARKER, isHereWorkspace, countClaudeSessions, ensureGitignored } from "./here.js";
-import { CliError, USAGE, parseArgs, nodeVersionProblem, explainListenError, } from "./args.js";
-/** This module's own directory: `<…>/packages/server/dist/cli`. */
-const moduleDir = path.dirname(fileURLToPath(import.meta.url));
+import { CliError, USAGE, SERVICE_USAGE, parseCommand, nodeVersionProblem, explainListenError, } from "./args.js";
+import { runService, safeHomeDir } from "./service/index.js";
+/**
+ * This module's own file and directory: `<…>/packages/server/dist/cli/`.
+ *
+ * `import.meta.url` is the module's REALPATH, which is why the service unit
+ * names this rather than `process.argv[1]` — npm installs a `bin` as a symlink,
+ * and a unit file pointing at `node_modules/.bin/paddock` would depend on that
+ * symlink surviving. (The same realpath-vs-argv[1] mismatch is what shipped a
+ * silent no-op to npm three times; see args.ts.)
+ */
+const entryScript = fileURLToPath(import.meta.url);
+const moduleDir = path.dirname(entryScript);
 /**
  * Walk up from this module looking for `rel`, returning the containing dir.
  *
@@ -95,6 +104,14 @@ function addBundledBinsToPath() {
  * `npx` is stateless enough that people reasonably assume the whole thing is
  * ephemeral. It is not — projects, chat transcripts, and settings all persist
  * here across runs, so say so once, at the moment the directory appears.
+ *
+ * The third line replaces `--here`'s discovery hint (#798). That hint scanned
+ * the CURRENT directory's Claude Code history and named a flag; both halves are
+ * gone. What a new instance actually offers is Discover (#745), which reads the
+ * whole history rather than one directory — so the CLI names it and lets the
+ * UI, which can show the list with tick-boxes against it, do the work. No
+ * filesystem scan happens here: the line is true whatever a scan would find,
+ * and an empty instance's Home leads with the same thing.
  */
 function noteFirstRun(dataDir) {
     if (fs.existsSync(dataDir))
@@ -103,57 +120,7 @@ function noteFirstRun(dataDir) {
         "",
         `  Welcome to Paddock. Creating a new instance in ${dataDir}`,
         "  Projects, chats and settings persist there between runs.",
-        "",
-    ].join("\n"));
-}
-/**
- * Say what `--here` is about to do to this directory, on the run that does it.
- *
- * The flag IS the consent — there is no prompt, and no `--yes` to remember.
- * But consent only means something if you can know what you agreed to, so the
- * effects are announced rather than asked about. Printed only on the first
- * `--here` in a directory; resuming an already-opened one says nothing.
- */
-function announceHereConsent(dir, dataDir) {
-    console.log([
-        "",
-        `  Opening ${dir} as a Paddock workspace.`,
-        `    · ${path.relative(dir, dataDir) || HERE_MARKER}/ and .chats/ created here, and added to .gitignore`,
-        // Worth stating because it is not what you would predict: paddock reading
-        // the home a user's sessions live in does not turn them into paddock's
-        // chats. Verified against a running instance — a pre-existing transcript
-        // for the directory comes back from `adoptable-chats` (offered) and NOT
-        // from `chats` (listed), because session discovery is attribution-based,
-        // not "whatever is in the folder". So #663's confirmation still gates
-        // every import.
-        "    · ~/.claude sessions for this directory are offered for import (nothing is moved)",
-        "  Later runs here resume it — no flag needed.",
-        "",
-    ].join("\n"));
-}
-/**
- * Tell the user their existing Claude history could be opened here.
- *
- * The only way anyone discovers `--here` exists. Read-only: a bare run counts
- * transcripts and prints, and changes nothing on disk.
- */
-function offerHereIfSessionsExist(dir) {
-    // The USER's own home, always: this is looking for `claude` history they made
-    // in a terminal, which is by definition in `~/.claude` and never in paddock's.
-    const claudeHome = path.join(os.homedir(), ".claude");
-    let sessions = 0;
-    try {
-        sessions = countClaudeSessions(claudeHome, dir);
-    }
-    catch {
-        return; // detection is a courtesy; never let it break a boot
-    }
-    if (sessions === 0)
-        return;
-    console.log([
-        "",
-        `  This directory has ${sessions} Claude Code session${sessions === 1 ? "" : "s"}.`,
-        "  Run `paddock --here` to open it as a workspace, where they can be imported.",
+        "  Open the app to find directories you have used Claude Code in.",
         "",
     ].join("\n"));
 }
@@ -175,18 +142,59 @@ function openBrowser(url) {
         /* as above */
     }
 }
+/**
+ * `paddock service …` — register/inspect the background service (#796).
+ *
+ * Split out so `main` stays the start path. Note what it is handed: the
+ * interpreter and script by absolute path, and `packageRoot` — which is tested
+ * for npx's cache, because a unit file pointing into a prunable hash-keyed
+ * directory rots at some future login with nobody watching.
+ */
+function service(command) {
+    const { action, opts } = command;
+    // Unreachable: `parseCommand` only omits the action when `--help` was given,
+    // which `main` has already handled. Typed rather than asserted.
+    if (action === undefined) {
+        console.log(SERVICE_USAGE);
+        return;
+    }
+    try {
+        runService(action, opts, {
+            platform: process.platform,
+            nodePath: process.execPath,
+            scriptPath: entryScript,
+            packageRoot,
+            homeDir: safeHomeDir(),
+            ...(process.env.PADDOCK_DATA_DIR !== undefined
+                ? { envDataDir: process.env.PADDOCK_DATA_DIR }
+                : {}),
+            ...(process.env.XDG_CONFIG_HOME !== undefined
+                ? { xdgConfigHome: process.env.XDG_CONFIG_HOME }
+                : {}),
+            ...(process.env.PATH !== undefined ? { pathEnv: process.env.PATH } : {}),
+        });
+    }
+    catch (err) {
+        if (err instanceof CliError)
+            fail(err.message);
+        if (err instanceof Error)
+            fail(err.message);
+        throw err;
+    }
+}
 async function main() {
-    let opts;
+    let command;
     try {
-        opts = parseArgs(process.argv.slice(2));
+        command = parseCommand(process.argv.slice(2));
     }
     catch (err) {
         if (err instanceof CliError)
             fail(err.message);
         throw err;
     }
+    const opts = command.opts;
     if (opts.help) {
-        console.log(USAGE);
+        console.log(command.verb === "service" ? SERVICE_USAGE : USAGE);
         return;
     }
     if (opts.version) {
@@ -196,23 +204,21 @@ async function main() {
     const problem = nodeVersionProblem(process.versions.node);
     if (problem !== undefined)
         fail(problem);
-    addBundledBinsToPath();
-    // Canonical, because working directories "MUST be canonical so session
-    // discovery (which encodes the real path) can find Claude transcripts"
-    // (config.ts). On macOS a /tmp vs /private/tmp divergence would silently
-    // break adoption — and macOS is most laptops.
-    let cwd = process.cwd();
-    try {
-        cwd = fs.realpathSync(cwd);
-    }
-    catch {
-        /* keep the literal path; the server will surface any real problem */
+    if (command.verb === "service") {
+        service(command);
+        return;
     }
-    // `--here` is the consent. A flagless run in a directory ALREADY opened this
-    // way resumes it — the git model, where `--here` is `git init` and `.paddock/`
-    // is `.git`. A flagless run anywhere else touches nothing.
-    const resuming = !opts.here && isHereWorkspace(cwd);
-    const hereMode = opts.here || resuming;
+    addBundledBinsToPath();
+    // NOTHING here reads `process.cwd()`, and that is the point (#798). `--here`
+    // used to make the current directory the workspace by setting
+    // `PADDOCK_PROJECTS_DIR = cwd`, which was the only place that variable was
+    // ever set from cwd. It also made the instance you got depend on where you
+    // stood — and because its marker directory was `.paddock`, the same name as
+    // the default data dir, a bare run from `$HOME` on any machine that had ever
+    // run paddock resumed `$HOME` itself as the workspace, silently, even with an
+    // explicit `--data-dir`. An instance is now decided by its data dir alone;
+    // directories are added inside the app as linked projects (Discover, #745),
+    // and the CLI writes nothing into any of them.
     // No Claude-home choice happens here any more (#691). The CLI used to point
     // `CLAUDE_HOME` at `~/.claude` so a macOS Keychain login would be visible
     // (#683); paddock now always owns its home, and what a user actually wanted
@@ -224,24 +230,8 @@ async function main() {
     // server resolves config inside `buildApp()`, so anything set before the
     // dynamic import below is picked up with no special-casing in config.ts.
     // Precedence is explicit flag > existing env > our default.
-    const dataDir = path.resolve(opts.dataDir ??
-        process.env.PADDOCK_DATA_DIR ??
-        (hereMode ? path.join(cwd, HERE_MARKER) : path.join(os.homedir(), ".paddock")));
-    if (hereMode) {
-        if (!resuming)
-            announceHereConsent(cwd, dataDir);
-        // The root workspace IS `projectsRoot` (its key is ""), so pointing this at
-        // the user's directory makes that directory the workspace. No schema change,
-        // no new project type — see cli/here.ts.
-        process.env.PADDOCK_PROJECTS_DIR = cwd;
-        fs.mkdirSync(dataDir, { recursive: true });
-        ensureGitignored(cwd, `/${HERE_MARKER}/`);
-        ensureGitignored(cwd, "/.chats/");
-    }
-    else {
-        noteFirstRun(dataDir);
-        offerHereIfSessionsExist(cwd);
-    }
+    const dataDir = path.resolve(opts.dataDir ?? process.env.PADDOCK_DATA_DIR ?? path.join(os.homedir(), ".paddock"));
+    noteFirstRun(dataDir);
     process.env.PADDOCK_DATA_DIR = dataDir;
     if (opts.port)
         process.env.PORT = opts.port;
@@ -288,13 +278,14 @@ async function main() {
         fail(explainListenError(err, host, port));
     }
     const url = `http://${host}:${port}`;
-    // ALWAYS name the workspace, not just in --here mode. Behaviour that varies
-    // with cwd is only safe if it is observable: "why is this instance different
-    // today" should be answerable by reading the two lines the tool just printed.
+    // Still name the data dir, even though it no longer varies with cwd: "which
+    // instance am I looking at" is a real question the moment anyone passes
+    // `--data-dir`, and the answer should be readable off the two lines the tool
+    // just printed rather than inferred.
     console.log([
         "",
         `  Paddock is running at ${url}`,
-        `  Workspace: ${hereMode ? cwd : dataDir}${resuming ? "  (resumed)" : ""}`,
+        `  Data: ${dataDir}`,
         "  Press Ctrl-C to stop.",
         "",
     ].join("\n"));

package/packages/server/dist/cli/service/backend.d.ts

@@ -0,0 +1,38 @@
+import type { ServiceSpec } from "./spec.js";
+export interface RunResult {
+    status: number | null;
+    stdout: string;
+    stderr: string;
+}
+/**
+ * Run an external command.
+ *
+ * Injected rather than imported so the install/uninstall/status flows can be
+ * driven in tests on a box that has neither `launchctl` nor a user systemd.
+ */
+export type Runner = (cmd: string, args: string[]) => RunResult;
+export declare const spawnRunner: Runner;
+export interface ServiceState {
+    /** Is a unit file installed for us? */
+    registered: boolean;
+    /** Does the init system say the process is up right now? */
+    running: boolean;
+    pid?: string;
+    /** The Paddock arguments recorded in the installed unit, interpreter stripped. */
+    argv: string[];
+}
+export interface ServiceBackend {
+    platform: "darwin" | "linux";
+    /** Where the plist / unit file goes. */
+    unitPath: string;
+    /** launchd label or systemd unit name — the string a user would type. */
+    label: string;
+    install(spec: ServiceSpec): void;
+    /** True if something was actually there to remove. */
+    uninstall(): boolean;
+    status(): ServiceState;
+    /** How to read the logs, as printed lines. */
+    logsHint(spec: ServiceSpec): string;
+    /** The `enable-linger` warning, or undefined where it does not apply. */
+    lingerNote(): string | undefined;
+}

package/packages/server/dist/cli/service/backend.js

@@ -0,0 +1,19 @@
+/**
+ * The seam between "what a Paddock service is" and "how this init system spells
+ * it" (#796).
+ *
+ * Two backends implement this: `launchd.ts` and `systemd.ts`. They differ in
+ * more than syntax — launchd wants log file paths and systemd sends everything
+ * to journald; systemd needs `loginctl enable-linger` and launchd has no
+ * equivalent — so the interface carries those asymmetries explicitly rather
+ * than pretending the two are the same shape with different quotes.
+ */
+import { spawnSync } from "node:child_process";
+export const spawnRunner = (cmd, args) => {
+    const r = spawnSync(cmd, args, { encoding: "utf8" });
+    return {
+        status: r.status,
+        stdout: r.stdout ?? "",
+        stderr: r.stderr ?? "",
+    };
+};

package/packages/server/dist/cli/service/index.d.ts

@@ -0,0 +1,28 @@
+import { type CliOptions, type ServiceAction } from "../args.js";
+import { isNpxPath, serviceDir, type ServiceSpec } from "./spec.js";
+import { type Runner } from "./backend.js";
+export interface ServiceContext {
+    /** `process.platform`. */
+    platform: NodeJS.Platform;
+    /** `process.execPath` — the interpreter the unit will name explicitly. */
+    nodePath: string;
+    /** Absolute realpath of `dist/cli/paddock.js`. */
+    scriptPath: string;
+    /** The `findUp("package.json")` root, tested for an npx cache path. */
+    packageRoot: string;
+    homeDir: string;
+    /** `process.env.PADDOCK_DATA_DIR`, if the installing shell had one. */
+    envDataDir?: string;
+    /** `process.env.XDG_CONFIG_HOME`, if set — where the systemd user unit goes. */
+    xdgConfigHome?: string;
+    pathEnv?: string;
+    run?: Runner;
+}
+export declare function runService(action: ServiceAction, opts: CliOptions, ctx: ServiceContext): void;
+/** Exported for the entrypoint's context assembly, and for tests. */
+export { serviceDir, isNpxPath };
+export type { ServiceSpec };
+/** Best-effort home dir; `os.homedir()` throws on a machine with no passwd entry. */
+export declare function safeHomeDir(): string;
+/** Realpath, falling back to the input — a broken symlink is not worth a crash. */
+export declare function realpathOr(p: string): string;

package/packages/server/dist/cli/service/index.js

@@ -0,0 +1,179 @@
+/**
+ * `paddock service install | uninstall | status` (#796).
+ *
+ * Registers Paddock as a **per-user** background service — a launchd
+ * LaunchAgent on macOS, a `systemd --user` unit on Linux — so it is up from
+ * login rather than for as long as a terminal tab.
+ *
+ * This file is the dispatch and the human output; the two backends do the
+ * writing and `spec.ts` holds every decision that is not init-system-specific.
+ *
+ * Three things this deliberately does not do:
+ *
+ * - **It does not set `PADDOCK_DATA_DIR`.** With nothing named, the service and
+ *   a `paddock` typed into a terminal both land on `~/.paddock`: one instance,
+ *   two ways to reach it.
+ * - **It does not generate an auth token.** A service is up longer than an
+ *   `npx` run, but not reachable by anything new: a local process that can
+ *   reach the port could already read the same Claude login as the same user.
+ *   Duration, not reach. `PADDOCK_AUTH_MODE` is there for anyone who wants one
+ *   anyway, and the bind-safety guard (#435) still refuses a routable interface
+ *   with auth off.
+ * - **It does not claim to start at boot.** See `launchd.ts`.
+ */
+import fs from "node:fs";
+import os from "node:os";
+import path from "node:path";
+import { CliError } from "../args.js";
+import { buildSpec, defaultDataDir, hostFromArgv, isNpxPath, NPX_REFUSAL, portFromArgv, serviceDir, } from "./spec.js";
+import { spawnRunner } from "./backend.js";
+import { createLaunchdBackend } from "./launchd.js";
+import { createSystemdBackend } from "./systemd.js";
+/**
+ * Pick a backend, or explain why there isn't one.
+ *
+ * Windows is the honest gap. It has no per-user service concept that maps onto
+ * either of these without a scheduled task or a service wrapper, and shipping
+ * an untested third writer would be worse than saying so.
+ */
+function backendFor(ctx) {
+    const run = ctx.run ?? spawnRunner;
+    if (ctx.platform === "darwin")
+        return createLaunchdBackend(run, ctx.homeDir);
+    if (ctx.platform === "linux")
+        return createSystemdBackend(run, ctx.homeDir, ctx.xdgConfigHome);
+    throw new CliError(`\`paddock service\` supports macOS (launchd) and Linux (systemd --user), not ${ctx.platform}.\n` +
+        "Run `paddock` in a terminal, or keep it up with whatever your platform uses.");
+}
+/** The data dir the service will use, and whether it has to be named explicitly. */
+function resolveDataDir(opts, ctx) {
+    // Mirrors `paddock.ts`: flag beats env beats default. An env var set in the
+    // installing shell is an explicit choice too — but it is one the service
+    // would NOT inherit, so it gets written into the unit rather than silently
+    // dropped in favour of ~/.paddock.
+    const chosen = opts.dataDir ?? ctx.envDataDir;
+    if (chosen !== undefined) {
+        const resolved = path.resolve(chosen);
+        return { dataDir: resolved, explicit: resolved };
+    }
+    return { dataDir: defaultDataDir(ctx.homeDir), explicit: undefined };
+}
+function specFor(opts, ctx) {
+    const { dataDir, explicit } = resolveDataDir(opts, ctx);
+    const spec = buildSpec({
+        nodePath: ctx.nodePath,
+        scriptPath: ctx.scriptPath,
+        dataDir,
+        ...(opts.port !== undefined ? { port: opts.port } : {}),
+        ...(opts.host !== undefined ? { host: opts.host } : {}),
+        ...(explicit !== undefined ? { dataDirArg: explicit } : {}),
+        ...(opts.verbose ? { verbose: true } : {}),
+        ...(ctx.pathEnv !== undefined ? { pathEnv: ctx.pathEnv } : {}),
+    });
+    return { spec, dataDir };
+}
+/** The line every surface has to carry, because otherwise it gets filed as a bug. */
+const AT_LOGIN = "  Paddock starts when you LOG IN, not when the machine boots — it runs as\n" +
+    "  you, so it can use the Claude login you already have. After a restart\n" +
+    "  that nobody logs into, Paddock is not running.";
+function install(opts, ctx, backend) {
+    if (isNpxPath(ctx.packageRoot))
+        throw new CliError(NPX_REFUSAL);
+    const { spec, dataDir } = specFor(opts, ctx);
+    backend.install(spec);
+    const url = `http://${hostFromArgv(spec.args)}:${portFromArgv(spec.args)}`;
+    const kind = backend.platform === "darwin" ? "a launchd LaunchAgent" : "a systemd --user service";
+    const linger = backend.lingerNote();
+    console.log([
+        "",
+        `  Paddock is installed as ${kind}, and running now.`,
+        "",
+        `  URL:  ${url}`,
+        `  Data: ${dataDir}`,
+        `  Unit: ${backend.unitPath}`,
+        backend.logsHint(spec),
+        "",
+        AT_LOGIN,
+        ...(linger !== undefined ? ["", linger] : []),
+        "",
+        "  paddock service status      is it up, and where",
+        "  paddock service uninstall   stop it and remove the unit",
+        "",
+    ].join("\n"));
+}
+function uninstall(ctx, backend) {
+    const existed = backend.uninstall();
+    console.log(existed
+        ? `\n  Paddock's ${backend.platform === "darwin" ? "LaunchAgent" : "user service"} is stopped and removed.\n  ${backend.unitPath}\n\n  Your data is untouched — it was never in there.\n`
+        : `\n  No Paddock service was installed (${backend.unitPath}).\n  Nothing to do.\n`);
+    // Leave the service directory: it holds logs, and the last thing anyone wants
+    // from `uninstall` is for the record of why they are uninstalling to vanish.
+    void ctx;
+}
+function status(opts, ctx, backend) {
+    const state = backend.status();
+    if (!state.registered) {
+        console.log([
+            "",
+            "  Paddock is not installed as a service.",
+            `  Looked for: ${backend.unitPath}`,
+            "",
+            "  paddock service install     register it and start it now",
+            "",
+        ].join("\n"));
+        return;
+    }
+    // Everything below is read back out of the INSTALLED unit, not recomputed
+    // from today's flags — the installed port is the one the URL has to name.
+    const url = `http://${hostFromArgv(state.argv)}:${portFromArgv(state.argv)}`;
+    const dataFromUnit = state.argv.indexOf("--data-dir");
+    const dataDir = dataFromUnit >= 0 && state.argv[dataFromUnit + 1] !== undefined
+        ? state.argv[dataFromUnit + 1]
+        : defaultDataDir(ctx.homeDir);
+    const { spec } = specFor(opts, { ...ctx, envDataDir: dataDir });
+    const linger = backend.lingerNote();
+    console.log([
+        "",
+        state.running
+            ? `  Paddock is running${state.pid !== undefined ? ` (pid ${state.pid})` : ""}.`
+            : "  Paddock is registered as a service, but not running right now.",
+        "",
+        `  URL:  ${url}`,
+        `  Data: ${dataDir}`,
+        `  Unit: ${backend.unitPath}`,
+        `  Args: paddock ${state.argv.join(" ")}`,
+        backend.logsHint(spec),
+        "",
+        AT_LOGIN,
+        ...(linger !== undefined && !state.running ? ["", linger] : []),
+        "",
+    ].join("\n"));
+}
+export function runService(action, opts, ctx) {
+    const backend = backendFor(ctx);
+    if (action === "install")
+        return install(opts, ctx, backend);
+    if (action === "uninstall")
+        return uninstall(ctx, backend);
+    return status(opts, ctx, backend);
+}
+/** Exported for the entrypoint's context assembly, and for tests. */
+export { serviceDir, isNpxPath };
+/** Best-effort home dir; `os.homedir()` throws on a machine with no passwd entry. */
+export function safeHomeDir() {
+    try {
+        return os.homedir();
+    }
+    catch {
+        return process.env.HOME ?? "/";
+    }
+}
+/** Realpath, falling back to the input — a broken symlink is not worth a crash. */
+export function realpathOr(p) {
+    try {
+        return fs.realpathSync(p);
+    }
+    catch {
+        return p;
+    }
+}

package/packages/server/dist/cli/service/launchd.d.ts

@@ -0,0 +1,47 @@
+import { type ServiceSpec } from "./spec.js";
+import type { Runner, ServiceBackend } from "./backend.js";
+/** `~/Library/LaunchAgents/net.edspencer.paddock.plist`. */
+export declare function plistPath(homeDir?: string): string;
+/**
+ * Render the plist.
+ *
+ * `KeepAlive` is a dict rather than `<true/>` on purpose: `SuccessfulExit:
+ * false` means "restart it if it exits nonzero, leave it alone if it exits
+ * cleanly". A bare `<true/>` would fight a deliberate `launchctl bootout` and
+ * make stopping Paddock a wrestling match.
+ *
+ * `EnvironmentVariables` carries PATH and nothing else. It carries PATH because
+ * launchd hands a process a stub PATH that a version manager's `node`, and the
+ * `git` an agent will want, are both missing from. It carries nothing else
+ * because a plist is a world-readable file in the user's home, and the one
+ * category of value that would be tempting to put here — a credential — is
+ * precisely what the agent shape exists to avoid needing.
+ *
+ * No `PADDOCK_DATA_DIR`: see `buildSpec`. One `~/.paddock` instance, reachable
+ * from the service and from a terminal.
+ */
+export declare function renderPlist(spec: ServiceSpec): string;
+/**
+ * Pull `ProgramArguments` back out of a plist we wrote.
+ *
+ * `status` reports the port the service is ACTUALLY installed with, which is
+ * only knowable from the installed unit — recomputing it from today's flags
+ * would print a confident URL for a server listening somewhere else. Regex
+ * rather than a plist parser because the input is a file this module wrote, in
+ * a shape this module controls, and adding an XML dependency to read it back
+ * would be the larger risk.
+ */
+export declare function parsePlistArgv(xml: string): string[];
+/**
+ * Read liveness out of `launchctl print gui/<uid>/<label>`.
+ *
+ * That command is the honest answer to "is it running": it reports the service
+ * as launchd currently understands it, including `state = running` and the pid.
+ * The alternative — checking whether the plist file exists — answers "is it
+ * registered", which is a different and much weaker question.
+ */
+export declare function parseLaunchctlPrint(out: string): {
+    running: boolean;
+    pid?: string;
+};
+export declare function createLaunchdBackend(run: Runner, homeDir?: string): ServiceBackend;