Google Jules Shutdown: Export Your Data and Migrate

Export your Google Jules data now, then repeat the export after your final coding sessions. As of 2026-11-01, Google says you can finish sessions until November 11, 2026, followed by read-only access through year-end. Jules winds down on December 31, 2026, according to the official shutdown notice.

The migration has two parts: preserve what Jules stores, then rebuild one working task in your replacement tool. Your repository alone does not contain the memories, environment configuration, and session history needed for that second step.

What should you finish before read-only mode?

Finish active work and preserve useful changes before November 11. Google’s notice says Jules becomes read-only after that date, but gives no cutoff time or timezone.

The notice also does not promise that the export endpoints will remain usable throughout read-only mode. Exporting before November 11 is therefore a conservative recommendation, not a separately announced export deadline.

Your existing code, branches, and pull requests remain in GitHub. Review unfinished sessions and publish useful changes where appropriate. Keep exported patches for work that has not reached a branch.

Google says Jules learnings are shaping Antigravity. That statement does not supply a migration procedure or guarantee that your Jules configuration will transfer automatically.

How do you export your Jules data?

Use Google’s complete export prompt with a local CLI coding agent. The prompt includes a Python script that retrieves account configuration, repository information, and session records.

Prepare the CLI and a private destination

Use Bash on macOS or Linux for the commands below. Have Node.js with npm, Python, and an installed CLI coding agent available.

Check the prerequisites:

node --version
npm --version
python3 --version

Use Python 3.9 or newer for the published script. This requirement follows from its use of str.removeprefix, which the Python reference dates to Python 3.9.

Install and authenticate Jules Tools:

npm install -g @google/jules
jules login
jules remote list --repo

Complete the browser sign-in yourself using the Google account whose Jules data you need. The final command should list the repositories connected to that account.

If repositories are missing, resolve that before exporting. Use the Google Labs Jules GitHub installation page to check the connection and repository access.

Create a private export directory from your home directory:

cd "$HOME"
umask 077
mkdir -m 700 "$HOME/jules-export"

If the directory already exists, stop and rename the previous archive before continuing. Keep that backup private. Use a fresh destination for the final export.

Start your installed coding agent from the same shell. For Claude Code, run claude; its quickstart covers installation and authentication if needed.

Run the complete official prompt

Open the shutdown notice, expand Show the export prompt, and copy the entire prompt, including its Python script. Paste it into your CLI agent.

On Linux, remove the prompt’s standalone secret-tool lookup preflight before submitting it. That command writes the stored secret to standard output, as the libsecret implementation shows. Tell the agent that you already completed the Jules CLI check.

Keep credential reads inside the exporter. Do not ask the agent to display the access token or the values in env-variables.json.

Let the agent save and run the supplied script from your home directory. When it finishes, request the printed counts, any errors, and the full destination path. The documented destination is ~/jules-export.

Check the archive before relying on it

Check error_count and the expected files, not only the final success message. The script’s sessions total counts listed sessions, including entries whose individual downloads failed.

The export is designed to preserve this material:

Material	Where to look	What to do next
Account settings, environment variables, and scheduled tasks	Account JSON files, including env-variables.json	Recreate relevant settings and secrets in the destination
Connected repositories	sources.json	Compare the list with your expected repositories
Repository memories, setup scripts, and test commands	Per-repository folders, when those records exist	Review and adapt them before use
Session prompts, plans, activity logs, and patches	Per-session folders, including readable summary.md files	Preserve history and recover unfinished work

Require error_count to be 0, then inspect representative old and recent sessions. Check your most important unfinished session separately. Confirm that its prompt, plan, activity records, and expected patches are present.

Setup scripts and test commands are recovered from session output metadata. If a required setup.sh is missing, inspect the repository’s configuration in Jules while it remains available.

Treat the folder as a configuration and history archive. Preserve the GitHub repository separately. Keep the entire archive outside repositories because env-variables.json contains actual environment-variable values.

Which export error are you seeing?

Refresh Google authentication when every call fails; check GitHub access when repository lookup alone fails. These are different branches in Google’s troubleshooting instructions.

Symptom	Likely cause or documented condition	Fix and verification
Every export call returns 401	The access token may have expired. Google says it lasts about an hour after login.	Run a Jules command or sign in again with jules login. Retry the repository check, then rerun the export.
ListSources returns 401 with missing required authentication credential, while other calls work	Google identifies a missing GitHub connection for this pattern.	Connect GitHub, confirm repository access, and rerun jules remote list --repo.
An expected repository is absent	The account connection or selected repository access needs checking.	Confirm the correct Google account and GitHub installation. Re-export and inspect sources.json.
An export endpoint returns 404 or 400	The exporter uses undocumented internal endpoints.	Record the failing call and status. Check the current official prompt before retrying; do not guess replacement endpoints.

If you have never used Jules with GitHub repositories, Google’s prompt permits skipping that connection. It says the export will then have no repository data. If you expect repository data, complete the connection and repeat the repository check before exporting.

Move memories and setup into your next agent

Migrate durable project knowledge and reproducible setup first. Keep the full session archive available as reference material.

Turn useful memories into project instructions

Review each repository’s memories against the current code. Keep valid build commands, architecture constraints, and recurring fixes. Remove stale advice, duplicated rules, and secrets.

Put shared instructions in a repository-root AGENTS.md. Codex reads this file, and OpenCode 2 uses it for project guidance. OpenCode 2 does not use CLAUDE.md as a fallback.

For an npm project with package-lock.json and a working npm test script, a small example is:

- Install dependencies with `npm ci`.
- Run `npm test` after code changes.
- Keep generated files out of manual edits.
- Report failing checks and unresolved setup requirements.

Merge reviewed instructions into existing files instead of replacing them.

For Claude Code, add this import to a repository-root CLAUDE.md, preserving any existing Claude-specific instructions:

@AGENTS.md

Claude’s memory documentation supports this shared-file arrangement. Start a new session and use /context to confirm that CLAUDE.md appears under Memory files.

Ask the agent to identify the required setup and test commands before allowing edits. This checks whether the migrated guidance is useful. For a longer-term structure, see memory for coding agents.

Rebuild the execution environment

Adapt the exported setup script to the destination’s runtime and lifecycle. Review working directories, runtime versions, package registries, secret access, and services before running it.

For Claude Code cloud sessions, open the environment editor and select Setup script. Use Choose file to load a reviewed script. The cloud environment guide explains the setup phases. Environment variables configured for the session are not yet set during the setup script, so do not assume Jules variable access carries over unchanged.

For Codex Cloud, create an environment for your GitHub repositories using the current cloud environment guide. Supply the reviewed installation and test commands. Use Install script for dependencies and Start skill for service startup. Review the prepared environment, publish it, and start a new task.

For local Claude Code or OpenCode, recreate the required environment locally or in a devcontainer. One option is to save reviewed installation commands as .devcontainer/setup.sh. In an existing .devcontainer/devcontainer.json, set postCreateCommand to bash .devcontainer/setup.sh. The Development Containers reference defines when this command runs.

Move secret values through the destination’s secret settings. Do not copy env-variables.json into project instructions or commit it alongside a setup script.

Finally, run the recovered test command in a fresh environment. Fix setup failures before asking the agent to change application code.

Recreate scheduled tasks after a manual run

Rebuild each recurring task from its exported prompt and schedule. Preserve its repository, intended branch, timezone, environment requirements, and expected output.

For Claude Code, cloud scheduled tasks are in research preview as of 2026-11-01. They are available on Pro, Max, Ultra, Team, and Enterprise plans, subject to organization controls.

Open Claude’s scheduled-task page and choose New task; some accounts show New routine. Enter the prompt, select the repository and cloud environment, and configure the schedule. Use Run now, then inspect History, following the scheduled-task guide.

For Codex-related local work, use Scheduled in the ChatGPT desktop app. The current scheduling documentation requires the computer and app to remain running when a task needs local files. Codex CLI does not provide the Scheduled management interface. Keep this requirement separate from Codex Cloud’s hosted execution.

For OpenCode 2, the official CI example uses standalone execution with provider credentials supplied as CI secrets. Once OpenCode 2 and the intended provider/model are configured, a first check can be:

opencode run --standalone "Read AGENTS.md and identify the setup and test commands. Do not edit files."

Inspect the reply in the workflow output. For GitHub Actions, begin with workflow_dispatch for a manual run, then add a schedule trigger. GitHub documents both in its workflow event reference. Scheduled workflows run from the default branch.

Before enabling unattended edits, review the OpenCode 2 permission changes. Confirm that the job can perform required actions without an unexpected interactive prompt.

Disable the old recurring task when the replacement passes its checks. Avoid running both schedules against the same work. Review the first few runs for duplicate changes, repeated failures, and unexpected usage.

Which Jules alternative should you choose?

Start with a hosted agent if your main requirement is work that continues after you close your laptop. Choose a CI-based route when controlling the runtime and model provider matters more than having a managed interface.

These recommendations use capabilities documented as of 2026-11-01:

Your requirement	Try first	What could change the choice
Hosted repository tasks with a reusable environment	Codex Cloud	If the hosted environment cannot reach required services or reproduce the build, evaluate a runner you control
Recurring managed coding tasks	Claude Code cloud sessions with cloud scheduled tasks	If preview availability or organization policy blocks scheduling, use an approved CI route
Control over model access and execution	OpenCode 2 in your CI runner	Choose a hosted agent if maintaining workflow setup, credentials, and permissions is unwanted work
Remote access to an existing Google-based development machine	Antigravity Remote Control	Its documented daemon needs the host machine to stay on; choose hosted execution if that is unacceptable

Antigravity’s documented Remote Control route operates on your machine. Evaluate that actual execution model before treating Google’s product direction as a replacement for Jules’s hosted environment.

For a CLI route, BetterToken documents API connections for Claude Code and OpenCode. Treat that model access separately from each tool’s account, hosted execution, and scheduling requirements.

Compare costs using the same trial task. Include the model usage, any required subscription, and runner costs that apply to your chosen route. An export does not establish which replacement will be cheapest.

Validate one task before completing the migration

Choose one bounded change with a clear expected result. Use the same repository revision, setup requirements, and test command when evaluating a replacement.

Confirm that the agent loads your instructions, prepares the environment, completes the task, and leaves a reviewable result. For hosted work, check that execution continues without your local session. For scheduled work, inspect a real scheduled run after the manual trial.

Use the agent task-completion checklist to verify changes and test results in their authoritative locations.

After your final Jules sessions, make a fresh export and check it again. Keep the private archive, the reviewed project instructions, and the replacement task’s evidence together in your migration record.