Google Jules Shutdown: Export Your Work and Move On

Google Jules Shutdown: The Dates That Change Your Work

Google Jules, Google's background coding agent, becomes read-only after November 11, before its final wind-down. Google's Jules Turndown notice is dated October 29, 2026.

The notice specifies no cutoff hour, time zone, separate API deadline, licence deadline, billing or refund date, or post-closure data-retention schedule. Treat those as unanswered questions, not dates you can infer from the table.

For a developer with an unfinished fix, the immediate job is deciding whether to finish it in Jules or carry the patch and remaining requirements into a new task. For an engineering lead, it is finding the dependencies that nobody sees during an ordinary code review: recurring prompts, setup steps, repository permissions and credentials.

Act now if Jules runs work for you. Teams whose completed changes are already merged and who need no Jules-held records have less to move. Teams evaluating agents without existing Jules work can skip the export and start with the execution decision below. Waiting to choose a long-term vendor is reasonable; waiting to preserve your work is not.

Preserve the Work Outside Your Git Repository

Code, branches and pull requests already in GitHub stay there. Google's export covers Jules-held settings, environment variables, schedules, repository connections, memories, setup scripts and session prompts, plans, logs and patches. See the official export instructions.

A pull request, or PR, is a proposed code change. It can preserve the patch without preserving the reason an agent chose it. A setup script might contain the missing package installation that made tests pass; a memory might explain why a tempting refactor was rejected. Review that material before turning it into instructions for another agent.

Use the export as an archive, then build a smaller handoff for each unfinished task. Include the repository and branch, the intended change, what is already done, the remaining acceptance criteria and the command that demonstrates success. Link supporting records instead of pasting an entire conversation into a new prompt.

For example, a dependency-upgrade task needs more than “finish the upgrade.” Preserve which compatibility failure remains, which files changed and which test reproduces the failure. That gives the next agent a bounded job and gives the reviewer a way to reject an incomplete result.

Export Through Google's Published Procedure

Google's route is Jules Tools plus its supplied export prompt. Install and authenticate:

npm install -g @google/jules
jules login

From your home directory, open a CLI coding agent and paste the expanded prompt from the notice. Connect GitHub first for repository data. Output goes to ~/jules-export; keep it private because env-variables.json contains credential values. Per-session records include summary.md, activity logs and diffs.

A completion message is not a completeness check. Inspection of Google's published exporter shows that its session count measures the sessions listed, even when fetching a session's details fails. It reports errors separately. It also recovers setup commands from session outputs, so inspect what was actually written before declaring a repository portable. This finding comes from reading the published script; no export was run for this article.

That distinction matters to the lead signing off the move. “The command finished” proves less than “the required patch, configuration and task context are present.” If an important record is missing, recover it while you still have access rather than assigning the next agent a reconstruction exercise.

What Happens to History and the Jules API?

Preserve history locally and retire your Jules automation dependencies. The shutdown notice does not promise an automatic history import into another agent or continued API service after closure.

Google's public Jules API documentation describes sessions and their activities, including creating work, approving plans and sending messages. Those are execution dependencies: an issue bot that creates a session needs a replacement even if nobody on your team opens the Jules website.

Inventory scripts, workflow files and integrations that call Jules. Record their inputs, the success signal they wait for and where they put results. A migration that only changes the prompt can still fail because the old integration expects a Jules session identifier or polls Jules activities for completion.

Do not treat a still-published API quickstart as an extension of the service's lifetime. In the absence of a separate endpoint schedule, use the service timeline as your planning boundary and move task creation before read-only operation. This is an operational recommendation, not an additional API date announced by Google.

For history, distinguish preservation from resumability. A saved plan helps another agent understand the task; it does not recreate the previous agent's running environment. Finish or checkpoint work so that another developer can reproduce the next step without opening Jules.

What Moves Into Antigravity, and What Exists Today?

Google Antigravity, Google's agent development platform, is where Google says it is bringing lessons from Jules. Google's official Jules announcement says it is working to combine remote autonomous background execution with Antigravity's development environment. It supplies no delivery date for that combination.

The available product already supports useful background work. The Antigravity App manages parallel agents, groups work into Projects and runs scheduled tasks. Google's Remote Control documentation describes browser access to sessions running on your laptops, desktops or servers.

The distinction is who supplies the computer. Remote Control is a window into an existing machine. It does not, by itself, establish that Google has provisioned a hosted replacement for Jules. A team that wants overnight maintenance must know which machine keeps running, who maintains its dependencies and what happens when it becomes unavailable.

Migration path: open the repository in Antigravity, reconstruct the necessary setup and instructions, then run a small task with a clear test. If the plan relies on remote access, verify the target machine and its availability. Add the recurring schedule after that workflow passes review.

Choose Antigravity when you want its development environment and can operate the execution host. If the requirement is “the developer closes the laptop and nobody maintains another machine,” evaluate a hosted option now instead of making the cutover depend on an undated feature.

Use Antigravity pricing for access and quota decisions, and Google Antigravity vs Cursor for the separate question of which daily development environment fits your work.

Move Background Tasks to an Execution Environment You Can Operate

Choose the runtime before choosing the agent's writing style. A runtime is the computer and software environment that execute the task. For this migration, the useful comparison is whether you operate that environment, the vendor hosts it, or your automation runs it through GitHub Actions.

The following paths are based on the vendors' current documentation. They are migration starting points, not a claim of identical features or an import format shared with Jules.

OpenAI Codex Cloud Tasks: Hosted Work With a Reusable Setup

OpenAI Codex Cloud is a hosted coding agent that can keep working while your computer sleeps. Each task has its own workspace, and you can inspect changes and test results before committing or opening a PR. The official Codex Cloud guide describes the current setup flow.

Migration path: in ChatGPT, choose Work in > Cloud, then create or select an environment. Connect the GitHub repositories, let Codex prepare the project, review its setup checks and publish the environment. Start a bounded task using the cleaned Jules handoff, then review its changes and test results.

The wall is environment access. A successful local test says little about a cloud task that cannot reach your package registry or required service. Supply the necessary network destinations and credentials in the environment settings, then verify the same test there.

Choose Codex when the main requirement is a hosted task queue with reusable project setup. Make the first trial a task whose correct result you can judge quickly, rather than an open-ended rewrite. The broader Codex vs Claude Code comparison covers the workflow choice beyond this shutdown.

Claude Code: Cloud Sessions or Repository Automation

Anthropic Claude Code offers cloud sessions that keep running after your laptop closes, plus a separate GitHub Actions integration for repository workflows. The right migration path depends on whether you are replacing an interactive task handoff or an automated trigger.

For cloud sessions: connect the repository, configure the cloud environment's setup, network access and variables, and start a scoped task. From an authenticated Claude Code terminal, claude --cloud starts cloud work. On the normal GitHub clone path, push the branch first so the session receives the intended commits. See Claude's cloud-session guide.

The wall is shared capacity and access: cloud sessions consume the account's Claude usage allowance, and organizational permissions can restrict them. An engineer's working personal setup does not establish that the company account can run the same workload.

For GitHub Actions: a repository administrator can run /install-github-app in Claude Code, follow the authentication setup and review the generated workflow PR. Start with an explicit @claude request, then add the recurring or event-driven job you are replacing. Anthropic documents the app, credential and workflow requirements in its GitHub Actions guide.

The wall here is workflow ownership. Someone must maintain triggers, credentials and permissions, and distinguish a failed setup from a failed coding task. Choose Actions when the repository event is the natural starting point. Our Claude Code GitHub Actions guide walks through that operating model.

GitHub Copilot's Coding Agent: Keep the Handoff in GitHub

GitHub Copilot's coding agent provides background implementation and testing within GitHub's workflow. Its current documentation distinguishes cloud sandboxes from GitHub Actions environments, so check the environment selected for the task. See Copilot on GitHub.

Migration path: confirm plan access and organization policy, select the repository and branch, and give Copilot a task with acceptance criteria and a request for a PR. Inspect its proposed changes and test evidence before merging. Carry the same issue description forward from the Jules inventory so you can tell whether the replacement fulfilled it.

The wall depends on the execution environment: GitHub Actions sessions modify a single repository, while cloud sandbox sessions can span repositories. Both work on a single branch and open a single PR per task. Split a migration that needs coordinated changes across branches into separately reviewable work.

Choose Copilot when your review queue and task ownership already live in GitHub. That keeps the handoff close to the issue and PR, but it still requires rebuilding the environment and instructions that Jules previously held.

What's Overhyped: Export Is Not Automatic Migration

The misleading shortcut is treating “Jules is moving into Antigravity” as an account-transfer plan. Google's statements describe product direction and a data export. They do not promise that your active sessions, schedules or memories appear in a replacement ready to run.

Another shortcut is treating browser access as proof of cloud execution. A browser can control a machine you operate or a machine a vendor hosts. The interfaces may look similar while the responsibility for keeping work alive is different.

Use a practical acceptance rule: the replacement must reproduce the required setup, complete a bounded task, expose its checks and deliver a reviewable change. Do not select it because it recognizes the same repository or produces a plausible plan. A plan is useful evidence of understanding; the passing workflow is the evidence that the migration works.

For an engineering lead, that makes the decision smaller. You do not need to settle every future coding-tool preference before the shutdown. You need a verified route for the jobs that would otherwise stop, with an owner who can diagnose failures.

Your Checklist for the Week

Make the first working replacement the priority, then expand it to the rest of the backlog.

• Inventory: list Jules repositories, unfinished sessions, recurring tasks and API callers. Assign an owner and destination to each continuing job.
• Preserve: run Google's export procedure, inspect errors and important files, and store the original archive privately.
• Finish or checkpoint: review outstanding patches and leave each continuing task with an understandable branch, requirement and test.
• Rebuild: configure the chosen runtime's dependencies, instructions, network access and credentials. Keep secret values out of ordinary task notes.
• Prove: run a small task through setup, implementation, testing and human review. Check the failure path as well as the successful PR.
• Cut over: move recurring triggers only after the replacement works. Disable duplicate submissions and retire obsolete access when it is no longer needed.

The Monday move is to choose an active repository, export its Jules context and complete a small replacement task through review. That gives you a usable migration pattern to repeat before the service stops accepting work.

Get the newsletter for practical guides to changes in developer tools.