# Google Jules Is Shutting Down: Dates, Data Export and Antigravity

The coding agent becomes read-only in November, leaving developers with a shorter migration window than the December shutdown date suggests.

By Paras Madan | 2026-10-30


Google announced on October 29 that Jules will shut down on December 31, 2026. Developers have until November 11 to finish sessions before it becomes read-only. Anyone using the asynchronous coding agent should separate unfinished code work from the task of saving its configuration and history.

## The Jules shutdown timeline

Google's [shutdown notice](https://jules.google/docs/changelog/) gives two deadlines: November 11 for finishing sessions, then a read-only period until the end-of-year closure. Code, branches and pull requests already stored in GitHub remain there.

For a team using Jules regularly, **November 11 is the operational deadline**. Waiting until December to review an unfinished task would leave less room to ask Jules to correct a patch or rerun the work.

A useful first pass is to identify which sessions produced code worth keeping, which changes still need review and which recurring tasks need a new owner. A generated patch can survive the service that created it, but someone still has to understand and test it.

## How to export Jules data

The notice provides an export workflow for account settings, environment variables, schedules, repositories, memories, setup scripts and session history, including prompts, plans, activity logs and patches. It saves them in a local folder.

The [Jules Tools reference](https://jules.google/docs/cli/reference) documents installation with `npm install -g @google/jules`, followed by `jules login`. That login opens a browser for Google authentication. Its `jules remote list --repo` and `jules remote list --session` commands list connected repositories and sessions, while `jules remote pull --session SESSION_ID` retrieves a completed session's results.

For the fuller archive, follow Google's export instructions rather than assuming that pulling a patch also saves the surrounding context. Afterward, inspect the output and any reported errors. Check at least one important session against what is visible in Jules before relying on the archive.

## Keep the export out of your repository

**The export includes environment-variable values**, according to Google. Keep that folder private and outside repositories; do not casually attach it to a migration issue or share it with another tool.

This creates a practical separation in the migration. A replacement coding agent may benefit from setup instructions and repository notes, but that does not mean it needs an unrestricted copy of every exported file. Review what each file contains before deciding where it belongs.

## What moves to Antigravity?

Google's [official announcement on X](https://x.com/julesagent/status/2115883717705261283) says it is bringing lessons from Jules into Antigravity, combining remote background work with an agent-first development environment. It describes a direction, not an automatic transfer of existing sessions.

The announcement does not establish that a saved Jules task can resume unchanged in Antigravity. Treat any replacement as a workflow to verify: can it access the right repository, run the same checks and return changes through the review process your team already uses?

The longer-term lesson for coding-agent adoption is to keep important instructions and verification steps portable. The code may already be in GitHub, while the reasoning behind how the agent builds and checks it remains inside a product that can disappear.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help AI founders turn technical launches and product decisions into clear stories that developers can understand and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).