BookmarkSweep ships in the public payload but depends on the private _X skill, so its launchd job fails every 30 minutes forever

[xmasyx]

Summary

BookmarkSweep.ts, InstallBookmarkSweep.ts and com.lifeos.bookmarksweep.plist.template ship in the public install payload, but the sweep's only two dependencies live in skills/_X/, an underscore-prefixed private skill that is not in the payload. On a public install the launchd job therefore fails on its very first step, forever, every 30 minutes.

Evidence

Shipped in the payload:

• LifeOS/install/LIFEOS/TOOLS/BookmarkSweep.ts
• LifeOS/install/LIFEOS/TOOLS/InstallBookmarkSweep.ts
• LifeOS/install/LIFEOS/TOOLS/com.lifeos.bookmarksweep.plist.template

Not shipped — LifeOS/install/skills/ contains 53 skills and no underscore-prefixed ones; skills/_X returns 404.

The hard dependency, BookmarkSweep.ts lines 43-45:

const X_DIR = join(HOME, ".claude", "skills", "_X");
const BOOKMARKS_TOOL = join(X_DIR, "Tools", "bookmarks.ts");
const BOOKMARK_ISSUE_TOOL = join(X_DIR, "Tools", "bookmark-issue.ts");

fetchBookmarks() spawns bun <BOOKMARKS_TOOL> fetch 50 --json. With the file absent, bun exits 1, so the sweep returns { error: "fetch exited 1" } and exits 0 having done nothing.

Observed on one public install: 458 consecutive runs, 0 successes, spanning two system versions and starting the day the job was first bootstrapped. Every log line is byte-identical apart from the timestamp:

{"ts":"...","fetched":0,"new":0,"created":0,"skipped":0,"auditExit":null,"issueUrls":[],"error":"fetch exited 1"}

Why this is a defect and not just an unused feature

DOCUMENTATION/Work/WorkSystem.md already documents the exclusion policy for exactly this class of component:

Private component — NOT in the public release payload. hooks/ULWorkSync.hook.ts and the _ULWORK skill are principal-specific (they target the private UL work repo) and are rsync-excluded from public releases, the same as any underscore-prefixed private skill.

BookmarkSweep.ts is in the same class. Its classifier prompt triages bookmarks into "UL work ideas" and its VALID_PROPERTIES set is newsletter, website, youtube, podcast, community, consulting, open-source, internal — a principal-specific taxonomy. But unlike ULWorkSync.hook.ts, the tool and its installer were not excluded.

The failure is also silent by design: the sweep logs to MEMORY/OBSERVABILITY/bookmarksweep.jsonl and always exits 0, so launchd reports a healthy job and nothing surfaces. A public installer who bootstraps it gets a permanently dead 30-minute timer that looks alive.

Proposed fix

Preferred — exclude the three files from the payload, consistent with _ULWORK and ULWorkSync.hook.ts. Nothing in install.sh references InstallBookmarkSweep, so no install path breaks.

If the tool should keep shipping, make the installer fail closed instead of arming a job that cannot work. In InstallBookmarkSweep.ts, before materializing the plist:

const BOOKMARKS_TOOL = join(HOME, ".claude", "skills", "_X", "Tools", "bookmarks.ts");

async function install(): Promise<void> {
  if (!existsSync(BOOKMARKS_TOOL)) {
    console.error(
      `[InstallBookmarkSweep] refusing to install: ${BOOKMARKS_TOOL} not found.\n` +
      `BookmarkSweep depends on the private _X skill, which is not part of the public payload.`,
    );
    process.exit(1);
  }
  // ... existing install path
}

That turns a permanently silent runtime failure into one loud message at the only moment a human is watching.

A third option, if neither fits: have fetchBookmarks() distinguish "dependency missing" from "fetch failed", so the log line says which of the two happened rather than reporting a generic exit code 458 times in a row.

[xmasyx]

Two more dangling references, and a missing prerequisite

Checking the rest of the payload, the sweep is not the only path into _X. The public install advertises an X-bookmark capability through three entry points, and the other two are dead in the same way.

skills/Upgrade routes to a workflow that is not shipped. SKILL.md maps "check bookmarks", "scan bookmarks", "twitter bookmarks", "X bookmarks", "bookmarks for upgrades" and "what have I bookmarked" to Workflows/TwitterBookmarks.md. skills/Upgrade/Workflows/ ships five files — AlgorithmUpgrade.md, FindSources.md, MineReflections.md, ResearchUpgrade.md, Upgrade.md — and that is not one of them. The same SKILL.md also documents State/twitter-bookmarks-seen.json, which nothing in the payload creates. So six trigger phrases resolve to a missing file.

Fix: either ship the workflow, or drop the row from the trigger table and the State/ line, so the skill stops advertising a route it cannot take.

Services.ts registers a service that cannot be installed. com.lifeos.bookmark-watchdog ("Watches the X bookmark → summarize/idea pipeline for stalls") has an install field that is a comment pointing at an Arbol worker, not a runnable command. It is also listed in DOCUMENTATION/Services/BackgroundServices.md as an opt-in service with a 4-hour cadence. Meanwhile com.lifeos.bookmarksweep — the one job that is installable, via InstallBookmarkSweep.ts — does not appear in that registry at all. The registry and the installable surface are inverted with respect to each other.

Fix: register the sweep and drop the watchdog, or mark entries whose install is not a command so the registry cannot present an uninstallable service as merely opt-in.

There is no documented way for a public install to authenticate to X. Nothing in the payload ships or documents an X credential, and no setup step asks for one. Since bookmarks.ts is not published, how the private path authenticates is not knowable from outside. One weak signal: the sweep gives bookmarks.ts fetch 50 --json a 45-second timeout, which points at an API call rather than a browser session — that is inference from the shipped code, not something I can verify.

This matters for whichever fix is chosen here. Publishing _X alone would not make the feature work on a public install; the credential path would still be undocumented. If the capability is meant to stay private, then all three surfaces above are advertising it to installs that can never run it, and the cheapest correct fix is to stop advertising it.

[danielmiessler]

Good catch, @xmasyx — BookmarkSweep was shipping in the payload but depends on the private _X skill. Fixed in source (excluded from the payload and dropped the dead route, in ShadowRelease/Upgrade), ships next release. Closing since the public repo is generated from that source.