Troubleshoot why Google Jules cannot see or work on your private Swift GitHub repository, with a step-by-step checklist covering permissions, org approval, and scoping.
You connected Google Jules, but your private Swift repository does not appear in the list, or Jules reports it cannot access the code. Tasks either cannot be dispatched or fail immediately.
This is one of the most common early stumbling blocks, and it is almost always a permissions or scoping issue rather than a bug.
The good news is that access problems are systematic. Working through the causes in order almost always surfaces the culprit.
This guide walks the checklist from most to least likely so you can restore access quickly.
Before you start, resist the urge to reinstall everything at random. Blindly disconnecting and reconnecting can leave you in a more confusing state than you began with, whereas checking each cause in sequence tells you exactly what was wrong and how to prevent it next time.
It also helps to distinguish two subtly different symptoms. If the repository never appears in the list at all, the problem is almost certainly scoping or approval, whereas if it appears but tasks fail the moment they run, the connection exists and the issue is more likely a permission or environment change. Naming which of the two you are seeing narrows the search immediately.
When you authorized GitHub, you may have chosen selected repositories and simply not included this one. That is the single most frequent cause.
GitHub app installations let you pick exactly which repos an app can see. If your Swift project was not on that list, Jules cannot see it.
Go to your GitHub settings, find the installed application, and review which repositories it can access. This is where the truth lives.
If the repo is missing, that is your fix in the next section.
This is especially easy to trip over when the project you want to work on was created after you first authorized Jules. A newly created repository is not automatically added to an existing selected-repositories installation, so you have to add it deliberately.
In GitHub, open your account or organization settings and navigate to the installed GitHub applications. Find the Jules integration.
Edit its repository access. You can either grant access to all repositories or add your specific Swift repo to the selected list.
For safety, prefer adding just the repository you need rather than opening access to everything. Least privilege remains the right default.
Save the change, then return to Jules and refresh. The repository should now appear as an available target.
If it still does not show after a refresh, sign out and back into Jules to force it to re-read your GitHub installation. A stale session on the Jules side occasionally lags behind a permission change you just made on GitHub.
If your repository belongs to a GitHub organization, an owner may need to approve the app before anyone can use it. Your personal authorization is not enough.
Organizations often restrict which third-party apps members can install. A pending approval will block access even though everything looks connected on your side.
Check whether the app shows as awaiting approval in the organization's settings. This is easy to miss if you are not an owner.
The resolution is to ask an organization owner to approve the installation, covered next.
The telltale sign of this cause is that your personal repositories connect fine while only the organization-owned one is missing. When the boundary of the problem lines up exactly with organization ownership, pending approval is almost always the reason.
Identify who owns or administers your GitHub organization. They control which apps are permitted.
Ask them to open the organization's third-party application settings and approve the Jules installation for the repositories you need.
If the organization has a policy of restricting apps, they may need to explicitly allow it. Explain that access is scoped to specific repositories, which usually eases approval.
Once approved, reconnect or refresh in Jules and confirm the repository is now visible.
When you make the request, give the owner the specifics they need to decide quickly: the exact app, the single repository you want scoped, and the permissions it requests. A precise, least-privilege ask is far easier to approve than a vague request for broad access.
It is easy to authorize Jules under a personal account when the repository lives under an organization, or vice versa. The connection succeeds but points at the wrong place.
If you have multiple GitHub accounts, confirm you signed in to the one that actually owns or has access to the repository.
Check the account context shown in Jules against the account that hosts your Swift project. A mismatch explains an empty repo list every time.
Reauthorizing under the correct account, or installing the app on the correct organization, resolves this class of problem.
This is a common trap for developers who keep separate personal and work GitHub identities. The fix is to be deliberate about which identity owns the target repository and to install Jules under that same account rather than whichever one you happened to be signed into.
If Jules worked before and suddenly cannot access the repository, someone may have revoked the app or changed its permissions.
Security reviews, offboarding, or a cleanup of GitHub integrations can inadvertently remove access. This is worth checking when access disappears unexpectedly.
Review the app's current status and permissions in GitHub settings. If it was removed, you will need to reinstall and re-grant access.
After reinstalling, scope it to the repositories you intend to use and verify the connection from within Jules.
On teams this happens more often than you would expect, because integration cleanups rarely announce which specific apps they touched. If access vanished right around the time of a security audit or a departing colleague's offboarding, that timing is your strongest clue.
After any fix, dispatch a tiny throwaway task such as adding a comment to a file. A successful pull request confirms access is truly restored.
To prevent recurrence, document which account and organization host your Jules integration. Ambiguity here causes repeated confusion on teams.
Keep the integration scoped to only the repositories that need it, and review that list periodically. Tight scoping is both safer and easier to reason about.
Finally, remember Jules is evolving, so if the interface differs from what you expect, consult the official documentation for the current connection flow rather than guessing.
A short note in your team's onboarding docs, naming the account that owns the integration and how to request repository access, prevents most of these problems from ever recurring. The cheapest fix is the one you never have to perform twice.
One more habit is worth building: when you add a new Swift project that you intend to route through Jules, update the app's repository access at the same moment you create the repo. Handling scoping as part of project setup, rather than discovering it later when a task mysteriously fails, keeps the whole integration predictable for you and your teammates.
Most often the repository was not included when you granted GitHub access, or an organization owner has not yet approved the app. Check the installed app's repository access list in GitHub settings and confirm any organization approval.
No, and you should not. Grant access to only the specific repository you want Jules to work on. You can update the selected-repository list in your GitHub app settings at any time.
A GitHub organization owner or admin approves third-party app installations. If your repo is org-owned and access is blocked, ask an owner to approve the Jules installation for the repositories you need.
The app may have been revoked or its permissions changed during a security review or cleanup. Check the app's status in GitHub settings, and reinstall and re-scope it if it was removed.