Skip to content

Jules retirement (ruled 2026-10-30) was never executed — dispatch crons, Jules-side schedules, secrets, and mcpx wiring all still live #5098

Closed

Description

@developing-today

Facts from a census run 2026-11-03. No recommendation in this issue — a decision is pending with Drew.

The ruling that was never executed

On 2026-10-30 the fleet ruled to move off Jules altogether; code#2265 was closed moot on that basis. The retirement was never executed. Everything below is still live today.

Live Muse dispatch crons (hatch-personal, enabled, ran 2026-11-03)

Jules-side scheduled tasks

Bolt/Palette scheduled tasks on Jules' side are still creating sessions: on 2026-11-03, two zettel sessions completed, plus code/nix/dezren39 sessions on 11-02 and 11-03. These are configured on Jules' side — no repo workflow calls the Jules API to create them.

Secrets

JULES_API_KEY repo secret is present in developing-today/code, developing-today/opencode, developing-today/openchamber, and dezren39/nix (set 2026-10-29). Absent in dezren39/fleet.

mcpx wiring

The mcpx daemon config offers a jules MCP server (@google/jules-mcp) plus antigravity-jules-orchestration. This is present both in the live ~/code/.mcpx.json and in home/common/mcpx-settings.nix — so it survives the cascade migration unless explicitly removed.

Key loaders still live

  • The opencode wrapper top-up in home/common/default.nix loads JULES_API_KEY from file when unset.
  • pkgs/agent-shell-env/env.sh loads it for shells.
  • agent-auth.sh runs a jules CLI health-check.
  • ~/.config/jules/api-key exists (mode 0600), and a systemd path watcher backs it up.

Correction of a prior claim

OpenCode's own config no longer contains mcp.jules — it is absent from the runtime overlay and from ~/.config/opencode/opencode.jsonc. The comment at home/common/default.nix L1185–1187 claiming JULES_API_KEY is consumed via mcp.jules → {env:JULES_API_KEY} is STALE. The key's actual consumers are: the dispatch crons above, the mcpx-offered MCP server, and the Jules-side schedules.

Dormant remnants

  • .opencode/skills/jules-automate-github-issues/ and jules-local-action-verification/ — present in the repo and in laptop skill dirs.
  • Workflow files named jules*.yml in code are OpenCode-era (their headers say so) — name remnants only, not Jules dispatch.

Pending decision

Decision pending with Drew (surfaced in chat 2026-11-03): execute the retirement in full, rescind it and keep Jules, or partial (stop autonomous dispatch, keep manual MCP access).

Acceptance criteria

  • Every Jules surface named in the issue is retired or explicitly kept with a reason: dispatch crons, Jules-side schedules, and any Jules labels/automation in the four repos
  • Post-retirement, no scheduled job errors or no-ops because of a half-removed Jules integration (one full cycle of the affected jobs observed or their configs verified)

Activity

  1. developing-today commented on Nov 3, 2026

    @developing-today
    ContributorAuthor

    Ruling recorded (Drew, 2026-11-03 13:44 CST): execute the retirement in FULL — decommission everything this issue tracks — under one governing constraint: for each removal, add something useful, roughly equivalent. The fleet loses the Jules door, not the capabilities.

    What that means in practice:

    • Daily top-issue dispatch (the two jules-daily-top-issue* crons) is rebuilt on the fleet's OpenCode dispatch machinery (pm-dispatch), same selection, same cadence.
    • Bolt/Palette passes (the Jules-side scheduled tasks) are rebuilt as scheduled pm-dispatch runs with the existing bolt/palette prompts, for the same repos.
    • Jules session supervision (jules-review) folds into the native OpenCode lane/orchestration system that already supervises sessions on the laptop server.
    • The mcpx jules MCP server's role is covered by mcpx fronting opencode itself.

    Execution phases: (0) record + recon, (1) stop the sources — dispatch crons, Jules-side schedules, and every non-terminal Jules session including the two AWAITING_USER_FEEDBACK ones, (2) credentials + wiring removal (repo secrets, laptop config, live mcpx config), (3) the OpenCode equivalents, proven with a real dispatch, (4) close-out here with the full removal→equivalent mapping and per-item evidence.

    — posted by the decommission run, as the app

  2. developing-today commented on Nov 3, 2026

    @developing-today
    ContributorAuthor

    Decommission executed — close-out (2026-11-03). Drew's ruling (execute the retirement in full; for each removal add something useful, roughly equivalent) was carried out in one pass. This issue stays open for the items under "What remains" — everything else is done, with evidence below.

    Removal → equivalent mapping

    Removed Equivalent / disposition
    jules-review cron (deleted) OpenCode session supervision is native: repo-queue worker-shift lanes claim and track dispatched sessions, the openchamber-conductor / openchamber-dispatcher / openchamber-babysitter crons supervise the laptop OpenCode server, and pm-dispatch annotates issues with task/session ids. Its Jules half has nothing left to supervise — all 270 Jules sessions are terminal (below).
    jules-daily-top-issue + jules-daily-top-issue-code crons (deleted) opencode-daily-top-issue + opencode-daily-top-issue-code crons — same daily 07:12 cadence, same backlog selection and bookkeeping (state file renamed opencode-top-issue-state.json), dispatching via pm-dispatch POST /v1/sessions with the issue attach key.
    Jules-side Bolt/Palette scheduled tasks (code, zettel, nix, dezren39) opencode-bolt-palette cron — daily 08:12 rotation over the same four repos, prompts fetched fresh each run from this repo's pm-dispatch-task prompt library (prompts/bolt.md, prompts/palette.md).
    action-outbox-processor jules action kinds Retired in the job definition: jules-message / jules-session / jules-approve now short-circuit to dropped — jules retired. No producers remain (jules-review deleted; the dashboard's session actions were the other writer) — the outbox file was checked directly: zero queued jules actions. OpenCode sessions are driven via pm-dispatch annotations/queue, not outbox kinds.
    JULES_API_KEY Actions secret in code, opencode, openchamber, nix No replacement needed — no consumer remains. Deleted and verified absent (re-listed, count 0) in all four repos.
    mcpx jules MCP server + antigravity-jules-orchestration (live config + repo config) mcpx already fronts opencode itself through the same gateway — the OpenCode route replaces the Jules route. Live daemon edited, restarted, verified (below); repo side in PR #5111.
    Config wiring: wrapper JULES_API_KEY top-up, agent-shell-env loader, agent-auth jules block, backup watch entry, two jules skills, stale mcp.jules comment PR #5111 — nothing needs the key locally anymore; removal is the point.
    Laptop ~/.config/jules/api-key Moved to the recoverable trash (~/.local/share/Trash/files/api-key on amd-6), not shredded.

    Evidence

    • Crons: the three Jules jobs were removed (definition files deleted from hatch-personal; the runtime archived copies under ~/workspace/cron.d/_archive/). action-outbox-processor kept with only its jules handling retired (definition edited + live job updated). New OpenCode jobs verified present in the live cron list; definition commits in hatch-personal: 913e900eb, c9f2d571c.
    • Jules sessions: stop/conclude messages sent via the Jules API to all 4 non-terminal sessions (the nix#1341 fix, the code#4887 fix, and the two upstream-sync sessions). Final fresh list: 270 sessions — 233 COMPLETED, 37 FAILED, 0 non-terminal. The nix#1341 session's work product exists as dezren39/nix PR id(web): Fix Go to Line undercounting lines due to hard breaks #1410.
    • Live mcpx: both jules entries removed from ~/code/.mcpx.json (17 → 15 servers); the daemon logged the removal itself (configuration changed on disk: [] added, [antigravity-jules-orchestration jules] removed), restarted clean (active/running), and an MCP initialize + tools/list spot-check returns 84 gateway tools with zero jules tools.
    • PR chore: remove Jules wiring from home config (decommission, #5098) #5111 (opened as the app, NOT merged): removals (a)–(g) plus one necessary companion fix — pkgs/agent-shell-env's installCheckPhase tested the removed Jules loader, so the test was retargeted to the surviving Cloudflare loader with the same assertions. home.activationPackage builds green in the worktree; every file the PR touches greps clean for jules afterwards.

    What remains (why this issue stays open)

    1. Jules-side scheduled tasks are UI-only. The Jules API exposes no schedule resource (GET /v1alpha/scheduledTasks and /schedules both 404; /sources works). A human (or a browser session) must open the Jules web UI and disable/delete: the Bolt and Palette scheduled tasks for developing-today/code, developing-today/zettel, dezren39/nix, dezren39/dezren39 — plus the two daily upstream-sync tasks (openchamber from openchamber/openchamber; opencode v2 from anomalyco/opencode dev) evidenced by their sessions. Until that happens those tasks may still fire, and the new opencode-bolt-palette cron overlaps them by design — the overlap was accepted and is flagged here rather than doubled silently.
    2. Proof dispatch blocked by an unrelated outage. The required proof — one real pm-dispatch dispatch for the orphaned issue id(hosted_binding): a pending delayed rebind does not reserve its target key — another account can bind it during the 30-day wait, and effect_due_rebind silently overwrites that binding's by-key index entry #4887 — was attempted 2026-11-03T19:58Z. pm-dispatch created and then closed tracking issue Fix #4887: id(hosted_binding): a pending delayed rebind does not reserv #5103 after its queue store failed: getaddrinfo ENOTFOUND nltgxorqwxhgfzseiirt.supabase.co. That hostname (Supabase project muse-dev2, the dispatch queue store) is NXDOMAIN from public resolvers (verified against 1.1.1.1 and 8.8.8.8) — the signature of a paused project. pm-dispatch writes are down fleet-wide until the project is restored from the Supabase dashboard. Once restored: re-run the dispatch (payload kept with the decommission run) or let opencode-daily-top-issue-code's first run (2026-11-04 07:12 CST) perform it — its definition reports dispatch failures loudly to the Repo sweeps chat instead of failing silently. id(hosted_binding): a pending delayed rebind does not reserve its target key — another account can bind it during the 30-day wait, and effect_due_rebind silently overwrites that binding's by-key index entry #4887 itself is untouched, still open and queued. (Also observed on the laptop: pm-git-sync.service is in a failed state — the pm services' deploy pipeline; flagged for the fleet separately, not fixed here.)
    3. Follow-up wiring the config PR deliberately left (separate pass, larger blast radius): pkgs/jules/, pkgs/jules-fleet/, pkgs/jules-merge/, pm-stack/aggregator/src/sources/jules.ts, the pkgs/agent-backup/backup.sh snapshot list (still names the api-key path), jules references under nixos/{agent-auth,environment,desktop,services/pm-stack}, secrets/sops/common/bws.yaml + lib/bws-to-sops.sh, and mcpx skill docs. Note: the jules.yml workflow filename and the jules label are NOT leftovers — they are the pm-dispatch hub's kept names by design.

    — posted by the decommission run, as the app

  3. added a commit that references this issue on Nov 3, 2026
  4. developing-today commented on Nov 3, 2026

    @developing-today
    ContributorAuthor

    Schedule close-out — Jules UI pass + API origin probe (2026-11-03)

    (a) Schedules DELETED in the Jules UI — 6

    Deleted via Scheduled → Delete schedule (not merely paused), each verified by the Scheduled view's empty state afterward ("Scheduled tasks will show up here"):

    • developing-today/zettel — "Palette: Micro-UX and Accessibility Improvements" — daily 08:30 — DELETED
    • developing-today/zettel — "Bolt: Performance Optimization Agent" — daily 08:30 — DELETED
    • developing-today/code — "Bolt: Codebase Performance Optimization Agent" — daily 20:00 CST — DELETED
    • developing-today/code — "Palette: Micro-UX and Accessibility Improvements" — daily 20:00 CST — DELETED
    • dezren39/nix — "Bolt: Codebase Performance Optimization Agent" — daily 00:00 CST — DELETED
    • dezren39/dezren39 — "Palette: Micro-UX and Accessibility Improvements" — daily 00:00 CST — DELETED

    (b) Anticipated but never existed — 2

    The sweep expected 8 Bolt/Palette tasks (both personas × 4 repos) and found 6. No Bolt task for dezren39/dezren39 and no Palette task for dezren39/nix were present in the UI.

    (c) Overlap risk with opencode-bolt-palette — gone

    With every Jules-side Bolt/Palette schedule deleted, the overlap risk flagged earlier in this decommission (the replacement OpenCode cron double-firing alongside a still-live Jules schedule) no longer exists.

    (d) Upstream-sync schedules — NOT found in the UI; origin probe inconclusive; item stays open

    UI sweep: no scheduled entry for either daily upstream-sync task was found. The Scheduled view of every connected codebase (all developing-today/* and dezren39/* repos in the account) was checked — all empty.

    API origin probe (read-only, 2026-11-03): the Jules API session resource carries no origin metadata at all. The union of fields across all 270 sessions in the account is exactly: createTime, id, name, outputs, prompt, sourceContext, state, title, updateTime, url — no scheduled-task id, no automation/creation-source field on any session. Attribution of a session to a schedule vs. an API/manual creation is therefore impossible from session metadata.

    What the session history does show:

    • Exactly two upstream-sync sessions exist in the entire account history, both created 2026-10-29 and both COMPLETED:
    • Despite the "daily" in their titles, neither ever recurred: no upstream-sync session exists after 2026-10-29 (checked 2026-10-30 through 2026-11-03).

    Disposition: this sub-item stays OPEN. Watch criterion: a new upstream-sync Jules session appearing after 2026-11-03 proves a non-UI origin that must be traced (the UI holds no schedule that could produce one). If none appears, the 2026-10-29 one-offs are the whole story.

  5. added
    kind/infrastructureInfrastructure / host-portability work
    priority/highImportant and time-sensitive
    effort/mMedium: expected under 1 day of work
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Nov 3, 2026
  6. dezren39 commented on Nov 3, 2026

    @dezren39
    Member

    Intake review

    Fleet monitor intake pass (2026-11-03T20:55:07Z): verified OPEN, no held/user/owned labels.

    Related (title-search of merged PRs):

    Notes: A merged PR appears to reference this issue — a worker must confirm whether it fully resolves it before closing; not closed by intake because the reference alone is not unambiguous resolution evidence. Acceptance criteria appended to the body. Priority: priority/high — a ruled retirement (2026-10-30) was never executed and the surfaces still run. Effort: effort/m.

    Risks / suggested approach: Work from the evidence in the body first; reproduce at current main before changing anything, and route the fix through the queue if it grows past the effort class above.

  7. dezren39 commented on Nov 4, 2026

    @dezren39
    Member

    Decision recorded 2026-11-03 (Drew, in the Repo sweeps chat): execute the FULL Jules retirement.

    Execution status:

    • Dispatch crons: jules-review, jules-daily-top-issue, jules-daily-top-issue-code are all disabled and inert (their OpenCode successors own the daily work). Deleting the saved definitions via the scheduler API returned "schedule does not exist" — the definitions remain on file but cannot run; flagged here so the record is exact.
    • Outbox: jules-message / jules-session / jules-approve actions are refused as retired.
    • Secrets: JULES_API_KEY verified ABSENT today in all four repos — Actions secrets (code, opencode, openchamber, nix), Dependabot secrets, and code's environment secrets (copilot, github-pages). The census entry is superseded; nothing to delete.
    • Laptop key surface: ~/.config/jules/ is empty (no api-key file) and no jules systemd user units/timers exist.
    • Repo wiring — queued: nix-side mcpx offer + JULES_API_KEY loaders + agent-auth check → chore: remove Jules wiring — mcpx jules server offer, JULES_API_KEY loaders, agent-auth jules check (code#5098 set) dezren39/darwin-nix#1453, triage task 9129. Code-side remnants (.opencode/skills/jules-*, jules*.yml names) → triage task 9130 on this issue. ci-policy prose → docs(ci-policy): ci-policy.md still treats jules.yml as load-bearing after the Jules decommission #5241 (task 8996).
    • Jules-side scheduled tasks: the Bolt/Palette schedules inside Jules' own UI are being disabled via a signed-in browser session; result will be posted here. The two upstream-sync Jules sessions blocked on Drew are abandoned under this ruling — no further responses will be sent to any Jules session.
  8. dezren39 commented on Nov 4, 2026

    @dezren39
    Member

    Jules-side scheduled tasks: verified GONE, 2026-11-03 ~23:45 CST. Checked the Scheduled tab for all six connected repos in the signed-in Jules web UI (developing-today/code, opencode, openchamber, zettel, dezren39/nix, dezren39/dezren39) — every one shows the empty state ("No scheduled tasks yet" / "Scheduled tasks will show up here"). No Jules-side schedule remains that can fire new sessions. Combined with the earlier items (crons disabled, JULES_API_KEY absent everywhere, outbox kinds retired), the remaining retirement work is the queued wiring-removal tasks: nix #1453 (triage 9129), code remnants on this issue (triage 9130), and ci-policy prose #5241 (triage 8996).

  9. dezren39 commented on Nov 4, 2026

    @dezren39
    Member

    Retirement update: nix #1453 CLOSED as already-clean (2026-11-03 ~23:50 CST). Its triage (task 9129) flagged the census paths as nonexistent, and that verified out — no JULES_API_KEY and no active Jules wiring anywhere in dezren39/nix; only explanatory retirement prose remains. Remaining retirement work: task 9130 (code remnants, this issue) and task 8996 (ci-policy prose, #5241), both queued.

  10. added
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    and removed on Nov 4, 2026
  11. dezren39 commented on Nov 4, 2026

    @dezren39
    Member

    agent-note:v1
    state: picked-up
    queue: repo-health-code-pilot
    task: 9130 (triage, worker repo-worker-code, lane bf419306-c4ef-470f-a553-beabf93239de)
    by: openchamber-scheduled-lane
    at: 2026-11-04T06:02:00Z

    Picked up the code-side retirement cleanup. Revalidating the two named skill directories and jules*.yml workflow names against current main, with the merged #5111 close-out as context.

  12. added
    queue/blockedQueue or user escalation state
    status/blockedQueue or user escalation state
    and removed
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 4, 2026
  13. dezren39 commented on Nov 4, 2026

    @dezren39
    Member

    agent-note:v1
    state: blocked
    queue: repo-health-code-pilot
    task: 9130 (triage, worker repo-worker-code, lane bf419306-c4ef-470f-a553-beabf93239de)
    by: openchamber-scheduled-lane
    at: 2026-11-04T06:13:00Z

    Blocked as packet_defect: the packet requires accounting for every code-repo Jules surface but scopes only the two removed skills and jules*.yml workflows. Current main still installs pkgs/jules-fleet and pkgs/jules-merge from nixos/environment/default.nix (lines 263-264, 415-416), and the aggregator collector still imports the Jules keeper-state source from pm-stack/aggregator/src/sources/jules.ts. These are outside the packet; please explicitly disposition them or provide a corrected scope. The named skills were removed in merged PR #5111. I added local, uncommitted comments to the three jules*.yml workflows clarifying they are not Jules dispatch; no PR was opened because the wider acceptance is blocked.

  14. developing-today commented on Nov 4, 2026

    @developing-today
    ContributorAuthor

    Follow-up wiring pass complete — PR #5376 merged

    The last recorded remainder of this decommission is done. PR #5376 merged as merge commit 2f366fd40145bd5c386c51d03f2add075e33222c (head f3844708, 30 files, +62/−2591), after independent review:

    • Packages: pkgs/jules/, pkgs/jules-fleet/, pkgs/jules-merge/ deleted, with their callPackage definitions and systemPackages entries in nixos/environment/default.nix and the agent-auth/jules-api-key sops wiring in nixos/agent-auth. gemini-cli is kept (only its jules-citing comment was trimmed). Verified: zero jules hits in any *.nix file at the merged head.
    • Aggregator: src/sources/jules.ts deleted; the collector's keeper-state read, julesSummary (feed/model/health), the live coverage entry, the SESSION_SOURCES entry, and the render verb-support branch are all removed. OpenCode and Muse sources untouched. What remains is stored-record tolerance only — SessionSource "jules" parsing/labels in model/derive/registry/render, which parses history and produces nothing.
    • Backup: the ~/.config/jules/api-key line is out of pkgs/agent-backup/backup.sh's CANDIDATES (only that line).
    • Secrets layer: google.jules-api-key and google.jules-oauth-creds are out of secrets/sops/common/bws.yaml (verified: the file still decrypts with a valid MAC); lib/bws-to-sops.sh changed comment examples only.
    • Kept by design, untouched: the jules.yml workflow filename, the jules label machinery, and the .jules/ journal convention.
    • Proof at the PR head: aggregator bun test 1562 pass with the only failures being the pre-existing feat(aggregator): source-conflict inbox — one resolvable queue for Project-vs-derived and Kaneo-vs-GitHub disagreements, with per-class trust rulings #1282 health-surface pair (fails identically on origin/main) plus a pre-existing intermittent events-store flake (also reproducible on origin/main; passes deterministically standalone on both trees); contract:check passes; home.activationPackage builds green.

    Two standing notes, neither a blocker:

    • The board's frozen Jules coverage row/cards clear on the next aggregator deploy — the merged source no longer emits them, but the running aggregator still renders its stored records until then.
    • The committed bws.yaml mirror is now ahead of Bitwarden by these two keys until the next bws-to-sops sync regenerates it — remaining housekeeping, not a live integration (no consumer reads the removed keys: the agent-auth declaration that consumed google.jules-api-key is gone in the same PR).

    With the dispatch crons replaced, the Jules-side schedules deleted (verified 2026-11-03), the secrets removed from all four repos, the mcpx wiring removed (#5111 + live daemon), all sessions terminal, and now the follow-up wiring merged, every item this issue tracks is resolved. The upstream-sync watch criterion stands as a note: if a new upstream-sync Jules session ever appears, its origin is non-UI and gets traced then. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

effort/mMedium: expected under 1 day of workkind/infrastructureInfrastructure / host-portability workmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/highImportant and time-sensitivequeue/blockedQueue or user escalation statestatus/blockedQueue or user escalation state

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions