Google Jules Is Shutting Down: How to Export Your Work and Move It

Published November 12, 2026 · by the AQ team

Yes. Google is shutting down Jules: its changelog says Jules turned read-only after November 11, 2026 and winds down on December 31, 2026. Google's export uses Jules Tools (npm install -g @google/jules, then jules login) and an export prompt you run with a CLI coding agent, and it saves your account settings, environment variables, scheduled tasks, connected repositories, memories, setup scripts and every session's prompt, plan, activity log and code patches to ~/jules-export. Your code, branches and pull requests already live in GitHub and stay there.

AQ (aq.dev) is a multiplayer coding harness where a team connects its existing GitHub repository, opens a work item for each task and runs real agent CLIs such as Claude Code and Codex in a persistent, isolated workspace on infrastructure the team owns or a machine AQ manages for it. AQ has no direct Jules importer; this guide covers moving the exported files by hand, wherever you go next.

Facts about Jules on this page come from Google's Jules Turndown changelog entry (October 29, 2026) and the Jules Tools reference, both checked November 12, 2026.

The dates

• October 29, 2026: Google announces the turndown and publishes the export prompt.
• Until November 11, 2026: you could keep finishing sessions.
• After November 11, 2026: Jules is read-only until the end of the year.
• December 31, 2026: Jules winds down.

The changelog gives no end date for the export and does not say whether it works during the read-only period. Google's export prompt says the endpoints it calls are undocumented and asks the agent to report a 404 or 400 instead of guessing at a fix.

What stays in GitHub and what you have to export

Every branch Jules pushed and every pull request it opened belong to your GitHub repositories, so the shutdown does not touch them. What lives only inside Jules is the configuration and history around that code. Google's export writes it to a folder with this layout:

Export checklist

Run these steps on your own computer, from your home directory. They follow Google's instructions; the checks in between are ours.

1. Install Jules Tools. Run npm install -g @google/jules (pnpm also works, per the reference). Check it with which jules.
2. Sign in. Run jules login yourself in a terminal. It opens a browser for Google sign-in. The access token it stores expires about an hour later, so start the export soon after signing in, and sign in again if calls start returning 401.
3. Confirm Jules can see your repositories. Run jules remote list --repo. If the export later reports a 401 on listing sources while other calls work, your GitHub account is no longer connected to Jules.
4. Copy Google's export prompt exactly. Open the changelog entry, copy the prompt and its script as written, and read them before running anything. Do not take the prompt from a third-party page.
5. Run it with a CLI coding agent from your home directory. Google gives Antigravity CLI as an example; any agent that runs shell commands with your approval can do it. Approve each command after reading it. The prompt tells the agent not to print your access token or the values in env-variables.json; stop the run if it starts to.
6. Expect partial failures. Google's prompt says the endpoints it calls are undocumented and asks the agent to report a 404 or 400 instead of guessing at a fix. Errors on single memories or sessions are recorded and skipped, and the script prints how many failed. Keep that count with the export.
7. Check what arrived. List the folder with ls ~/jules-export ~/jules-export/repos ~/jules-export/sessions and compare the number of session folders with the sessions you remember. Google notes the export can find more sessions than jules remote list --session shows.
8. Pull any patch you still want. Each patch-N.diff applies with git apply on a fresh branch of the matching repository. A patch that was already published lives in GitHub, and summary.md names the published commit.
9. Copy the folder somewhere durable. Archive it to storage only you can read, for example an encrypted disk or a private bucket. Keep it out of every git repository.

Keep the export private

• env-variables.json holds real values. Google's notice says to keep the export folder private and out of your repositories. Restrict it to your user (chmod -R go-rwx ~/jules-export on macOS or Linux).
• Never print secrets while checking the files. Google does not document the shape of env-variables.json, so no single command reliably shows only variable names. Open it in a local text editor when nobody can see your screen, copy the values you still need straight into the destination secrets store, and close it. Do not print it in a shared terminal, and do not paste it into a chat, an issue or an agent prompt.
• Never print the access token. The export reads it from your system keychain (or ~/.jules/cache/oauth_creds.json). Leave it there, and run jules logout when you are done.
• Rotate what you are unsure about. If a value from env-variables.json may have reached a log, a commit or a shared screen, rotate it at the service that issued it.
• Search the patches and activity logs before sharing them. They record what the agent ran and changed, which can include values it read. Search for your secret names before you hand the folder to anyone.

Move the parts that matter

Nothing in the export imports itself anywhere. Each part has a plain destination.

Setup scripts and test commands

Commit each repos/<repo-id>/setup.sh into its repository, for example as scripts/setup.sh, after checking it contains no secret values. Put the line from test-command.txt in your README or your agent instructions file so every agent runs the same tests. Then point your next tool's setup step at the committed script.

Memories

Read memories.md for each repository and keep only the notes that still hold: build quirks, conventions, commands that work. Move those into an instructions file in the repository, such as AGENTS.md, which Codex, Cursor and many other agents read, or CLAUDE.md for Claude Code. Drop notes about one-off sessions, and write the kept ones as short rules.

Environment variables

Re-enter each variable in your next tool's secrets store by hand, one at a time, from env-variables.json. Skip variables you no longer use. If you can, issue new values instead of reusing the old ones.

Scheduled tasks

Open scheduled-tasks.json and write down each task's prompt, repository and timing. Recreate the ones you still want in a scheduler you control: a CI schedule such as a GitHub Actions cron workflow, or a bot routine. Run each recreated task once by hand before you rely on its schedule.

Session history

Keep sessions/ as an archive. A session's summary.md and plan explain why a change was made, which helps when you revisit that code. Link the relevant summary from the pull request or issue if your team needs it later.

Where AQ fits

AQ is a multiplayer coding harness at aq.dev where teams run AI coding agent CLIs in isolated workspaces on a machine of their own. If you are moving Jules work to AQ, the steps are:

1. Connect the same GitHub repository. Your branches and pull requests from Jules are already there.
2. Open a work item for each task. Each work item gets its own branch and git worktree, so parallel tasks do not collide. See AQ Docs: workspaces.
3. Run a real agent CLI in it. Claude Code, Codex, Cursor, Antigravity and others run signed in with your own accounts, or you use AQ's built-in agent. The workspace stays on that machine between turns.
4. Have an admin add your setup script as the repository's setup command, so every new work item runs it.
5. Add the variables as personal or organization secrets, which agents receive as environment variables. See AQ Docs: secrets.
6. Put the kept memories in the shared rules every agent reads, or in the repository's own AGENTS.md. See AQ Docs: memory.
7. Recreate scheduled tasks as bot routines on a daily, weekly or monthly schedule. See AQ Docs: bots.

Where agents run depends on the plan: the Free plan runs them on your own Mac with the AQ Mac app, and the AQ Pro plan adds an AQ-managed cloud machine or your own cloud. For other hosted options, see the best cloud coding agents.