Google’s migration notice says Jules sessions can continue through November 11, 2026, and then become read-only; service ends on December 31, 2026 (official announcement). The safest Google Jules migration is to export service data now, finish or hand off sessions that still need interaction before the cutoff, and test a replacement workflow on a real repository. GitHub code, branches, and pull requests are not part of the Jules export, and Google has not confirmed automatic transfer to Google Antigravity.
Who should read this
Independent developers who need to preserve personal settings, environment variables, and unfinished work.
Small teams relying on scheduled Jules tasks or shared repositories.
CI and platform engineers responsible for agent permissions, tests, and macOS build steps.
Last updated November 5, 2026. Dates and export scope checked against the Jules migration announcement and Jules Tools CLI reference. Check those sources again before acting in case Google changes the schedule or instructions.
The migration timeline: finish interactive work before exporting
The cutoff is not a single “move everything” event. It creates a short window to finish work that needs Jules interaction, followed by a read-only period in which preservation and handoff become more urgent than continuing the same workflow.
| Time | Jules status | What to do |
|---|---|---|
| Before November 11, 2026 | Sessions can still be completed | Finish, review, or hand off sessions that need further interaction. Export Jules data and confirm the result. |
| November 11 through December 31, 2026 | Jules is read-only | Retrieve or inspect remaining information as permitted, but do not plan on continuing interactive work. Keep replacement workflows and repository access operating independently. |
| After December 31, 2026 | Jules service ends | Maintain the export, repository records, and replacement workflow under named team ownership. |
These dates come from the official migration notice. The announcement does not establish a cutoff time or time zone in the information cited here. Teams with a deadline close to the date should check the announcement for updates and complete interactive work earlier rather than relying on the final hours.
The first decision is about unfinished work, not which replacement agent to choose. A session that is still running, waiting for input, or expected to produce a deliverable needs an explicit owner and next action. An exported transcript may help explain what happened, but it does not finish a task or confirm that a pull request is ready to merge.
A practical handoff record for each open session should identify the repository, intended change, current branch or pull request if one exists, expected artifact, validation command, and person responsible for review. Include any unresolved question or dependency that would prevent another engineer from continuing. Treat a task as handed off only when the successor can find these details and knows what result to verify.
Deadline reminder: A task that is merely visible in session history is not necessarily complete. Check its repository state and test evidence separately.
Separate Jules service data from work already stored in GitHub
The key boundary is between information held by Jules and work already saved in GitHub. The official notice says existing code, branches, and pull requests in GitHub are outside the Jules export. That means a successful export does not copy those assets—and, conversely, a Jules export should not be mistaken for a backup of the repository.
| Information or asset | Where to verify it | Migration action |
|---|---|---|
| Repository code, branches, and pull requests | The relevant GitHub repository | Confirm access and repository state using the team’s normal process; do not expect Jules export to include these assets. |
| Jules settings and connected-service information | Local Jules export output | Inspect the exported files and compare them with the settings needed for continued work. |
| Environment variables and setup scripts | Export output and the team’s secret-management process | Confirm expected files exist, restrict access to sensitive values, and do not commit secret-bearing files to a repository. |
| Scheduled tasks, memories, and session records | Export output and the Jules interface where available | Identify which items need manual recreation, documentation, or no further action. |
| Replacement-agent permissions and tests | The replacement environment and repository | Recreate only what the task requires, then test access, execution, and review behavior. |
The exact export contents should be checked against the current Jules migration notice, not inferred from a familiar file name or from a successful command exit. The announcement lists settings, environment variables, scheduled tasks, repository connections, memories, setup scripts, and session activity among the material to review. The Jules Tools CLI reference is the source for the current tool instructions.
Before the deadline: resolve open sessions
Start with a session inventory. Sort entries into work that is complete and reviewable, work that needs another interaction, and work that can be stopped or recreated elsewhere. Prioritize anything tied to a delivery date or a workflow that depends on Jules continuing to execute.
For each session that must continue, record its current state in the repository where possible. Make clear whether the agent has proposed changes, created a branch, opened a pull request, or only produced discussion. Assign a human reviewer and capture the test or acceptance criteria. This avoids treating conversational history as proof that code was committed or validated.
Where a task is blocked, record the blocker and the smallest useful next step. If another engineer or agent will take over, provide repository and branch context through the team’s approved access process rather than copying credentials into notes. For completed tasks, verify the repository artifact and review record independently of the session transcript.
Install, authenticate, and export with Jules Tools
Use the local export procedure in the official migration notice. Follow the current Jules Tools CLI reference for installation, authentication, and command syntax; do not rely on a command copied from an old shell history or an unofficial snippet. This matters because an apparently successful login or listing operation is not the same as a completed export.
Before running the export, check that the account is the one associated with the Jules data being preserved, that the local environment has permission to write to the intended destination, and that there is enough protected storage for the output. Avoid placing the export in a public or shared directory by default. If the tool reports a partial result, an authentication issue, or a write failure, resolve that condition and repeat the export rather than assuming the archive is complete.
Afterward, locate the output using the destination and completion details given by Jules Tools. Preserve the original export as an archive, then inspect a working copy. Consult the current CLI reference for the tool’s behavior; this guide does not assume a fixed output path or invent command flags that may change.
Security note: Environment variable exports can contain credentials or other sensitive values. Restrict access and follow the organization’s secret-handling policy. GitHub’s documentation on secret types and secret security is a useful reference for recognizing values that should not be exposed in source control.
After export: check the archive and protect sensitive values
Verify the export against the categories in the official notice. Look for expected configuration, environment variables, task schedules, repository connections, memories, setup scripts, and session activity. A missing item should become a tracked migration task, not a silent assumption that another agent will reconstruct it.
Review the archive with the same care used for credentials. Keep an access-controlled original, share only the files a teammate needs, and avoid committing the export wholesale to a repository. If sensitive values were included, follow the organization’s rotation and incident-handling rules where appropriate. The xcoderent privacy guide can also help teams frame questions about access and data handling when evaluating a remote development environment.
Do not test completeness by opening only a few session records. Compare the export contents with the settings and workflows the team actually uses. For example, a repository connection may exist in the archive while its replacement still needs a separately granted token or permission. A remembered prompt or setup script may be present but lack an external dependency, scheduled trigger, or access rule required for execution.
Choose the replacement by task, then test it against evidence
Google’s reference to Google Antigravity does not confirm an automatic Jules import or feature equivalence. Its product page describes Antigravity; it does not, by itself, establish that Jules settings, memories, scheduled tasks, or session history can be transferred. Treat any claim of automatic migration as unconfirmed unless Google publishes explicit instructions.
That distinction changes the decision. If the immediate need is to preserve context, the export and a concise handoff record are the dependable artifacts. If the need is to resume automation, select a replacement based on the task’s trigger, repository access, runtime, and review requirements. Do not choose solely because another product is also described as an agent.
For a recurring GitHub coding workflow, document what starts the task, what permissions it receives, where changes appear, which tests must pass, and who approves the result. Then recreate only the necessary pieces. A scheduled task may need a new scheduler; a repository connection may require renewed access; a memory may need to become written project documentation. These are distinct migration jobs, not one generic “import.”
For macOS-dependent work, validate the build host separately. If a task requires Xcode, a Linux runner cannot stand in for the macOS toolchain simply because the agent can read the repository. Check Apple’s Xcode system requirements for the relevant release, then verify the actual project build and test steps on a compatible Mac environment.
Use this verification checklist before calling migration complete
- [ ] Every Jules session that still needed interaction before the cutoff has been completed, stopped deliberately, or handed to a named owner.
- [ ] The Jules export was produced through the official local flow, and the output location is recorded.
- [ ] Expected settings, environment variables, scheduled tasks, repository connections, memories, setup scripts, and session records have been checked.
- [ ] Sensitive files are access-controlled and have not been committed to a repository.
- [ ] GitHub code, branches, and pull requests have been checked in GitHub rather than assumed to be present in the Jules export.
- [ ] A representative task has been recreated with its repository, dependencies, permissions, trigger, test command, and reviewer documented.
- [ ] The replacement has produced a reviewable result, the project’s tests have been run, and a human has checked the change.
- [ ] Any Xcode or other macOS-specific build step has been tested on an appropriate Mac environment.
- [ ] A person or team owns the export archive, repository access, and future maintenance of the replacement workflow.
Keep test evidence with the handoff: a run log, test result, pull request, or review note is more useful than a statement that the new agent “worked.” For a repeatable task, capture the input and expected outcome so another engineer can reproduce the check without access to the old Jules session.
FAQ: migration decisions teams still need to make
Do GitHub repositories need to be exported again from Jules?
No. The official notice identifies code, branches, and pull requests already in GitHub as outside the Jules export. Check those assets directly in the relevant repositories and confirm the team can still access them. If the organization has separate backup or retention requirements, follow those independently; the Jules export neither replaces nor proves that those controls are working.
Does an Antigravity mention mean Jules settings will import?
No. A product mention is not a migration specification. Until Google publishes explicit import instructions, plan to recreate required settings and workflows manually or through a separately verified process. Test a representative task before moving regular work, and retain the Jules export as reference material rather than treating it as a ready-to-import package.
What if an export item is missing or unreadable?
Record the missing category, check the current CLI instructions and export result, and repeat the procedure if the tool indicates an incomplete run. Preserve any useful information still accessible through Jules before its read-only period ends, while respecting the official schedule. If the data remains unavailable, document the gap and assign an owner to reconstruct only what the replacement actually needs.
Should every Jules memory become a prompt in the replacement agent?
No. First decide whether a memory contains a durable project rule, temporary task context, or obsolete information. Convert durable requirements into reviewed project documentation or workflow instructions; do not blindly copy private or sensitive material into another system. Validate the new instructions against a representative task and remove anything the replacement does not need.
How should macOS-only builds fit into an agent migration?
Separate agent behavior from build-host capability. Confirm that the project’s required tools and tests run in the intended macOS environment, then verify how the replacement workflow reaches that environment and reports results. Apple’s Xcode requirements are a starting point for compatibility checks, but a successful build of the actual project is the acceptance evidence.
After the read-only period: assign owners and keep the handoff usable
Before Jules becomes read-only, store the export where the responsible team can find it and record who can access it. Keep the GitHub repository as the source of truth for committed work, and link each unresolved session to its follow-up issue, pull request, or owner. After service ends on December 31, 2026, the team should not depend on Jules being available to explain undocumented decisions; that date is specified in the migration announcement.
Record which workflow elements were copied, manually rebuilt, replaced, or intentionally dropped. The record should include the tested repository, required permissions, trigger, dependency setup, validation command, reviewer, and result. If Google later publishes a confirmed import path or changes the dates, update the plan against that official information rather than relying on speculation.
A remote Mac is not a universal answer to an agent migration. It is relevant when the replacement workflow must run Xcode or another macOS-only toolchain, or when a team needs a continuously available Mac build environment. It does not automatically restore Jules history, schedule tasks, or validate agent behavior. For teams comparing a rented Mac with buying hardware, the Mac purchase and rental comparison can help assess the environment decision. If the workflow is Linux-compatible and does not require macOS, another runner or local setup may be simpler. If work is stable, heavy, and continuous, owning suitable hardware may also be preferable.
The migration is ready only when the export has been inspected, unfinished work has an accountable handoff, and a representative replacement task has passed repository, test, and review checks. If those checks reveal a genuine macOS requirement, xcoderent can be considered for a remote Mac environment; the choice should follow the build requirement, not the mere fact that Jules is changing status.
Frequently asked questions
When does Google Jules become read-only, and what should be finished first?
Google’s migration announcement says sessions can continue through November 11, 2026, after which Jules becomes read-only until service ends on December 31, 2026. Before the cutoff, finish or hand off sessions that need further interaction. Export settings and history as well, because read-only access is not a substitute for preserving service data.
How do Jules Tools export settings, environment variables, and session history?
Use the local export flow described in the official Jules migration announcement, following the current Jules Tools CLI reference for installation, authentication, and command syntax. Check the export output before relying on it: confirm that the expected settings, environment variables, scheduled tasks, repository connections, memories, setup scripts, and session records are present.
What does the Jules export include, and do GitHub repositories need a separate backup?
The official notice describes exportable Jules service data, including settings and session-related information. It explicitly excludes code, branches, and pull requests already stored in GitHub. Those GitHub assets do not need to be re-exported from Jules, but teams should still verify repository access, branch protection, and the normal backup or retention policy independently.
Will Google Antigravity automatically take over Jules tasks and settings?
No automatic import or feature-for-feature replacement has been confirmed in the cited official material. Google’s mention of Antigravity is not a migration guarantee. Treat it as a separate product unless Google publishes explicit import instructions, then test your own repository, credentials, triggers, and review process before moving production work.
How can a team verify a replacement agent after migrating from Jules?
Choose a representative task that can be repeated safely, then check repository access, dependency setup, permissions, trigger behavior, test commands, generated changes, and human review. Keep the original task description and expected result as a reference. If the workflow depends on Xcode or another macOS-only toolchain, validate that build environment separately rather than assuming an agent test covers it.
Validate Your New Workflow on a Dedicated Mac
Run your build and test workflow on a dedicated physical Mac mini, not a virtual machine.