Why does SourceTree stop showing local branches when custom Git refs like refs/codex exist?

[添喜黄]

Title: SourceTree stops showing local branches after custom Git refs are created

SourceTree stops showing local branches in my repository after the OpenAI Codex VS Code extension creates custom Git refs.

Environment

• OS: Microsoft Windows NT 10.0.26220.0 x64
• Git client: SourceTree
• IDE: Visual Studio Code
• Extension: OpenAI Codex IDE extension
• Extension version: 26.609.30741
• Remote: Bitbucket

Problem

After starting a Codex chat in VS Code, custom Git refs are created under:

refs/codex/turn-diffs/checkpoints/...

After that, SourceTree stops showing local branches.

Sometimes fetch also fails with errors like:

fatal: bad object refs/codex/...

error: bitbucket.org:... did not send all necessary objects

Git CLI still shows the local branches correctly:

git branch

Workaround

Deleting the refs/codex refs fixes SourceTree immediately:

git for-each-ref --format='delete %(refname)' refs/codex | git update-ref --stdin

After running that command, SourceTree shows local branches again and fetch works.

Reproduction Steps

1. Open a Git repository in VS Code.
2. Start a chat using the OpenAI Codex extension.
3. Refs are created under refs/codex/turn-diffs/checkpoints/....
4. Open the same repository in SourceTree.
5. Local branches disappear, or fetch fails.
6. Delete refs/codex.
7. SourceTree works again.

Expected Behavior

SourceTree should continue to show local branches and fetch normally, even when custom Git refs exist in the repository.

Screenshot:

[Tomislav Tobijas]

Hi @添喜黄 ,

Might be that this is caused by Sourcetree's inability to handle non-standard Git references. Like, when Codex extension creates refs, it could be that it creates "dangling" or "bad" references. 🫤
In the end, I believe Sourcetree relies on a clean git for-each-ref output to populate its UI.

Anyway, you could streamline this process you've found into something like this:

1. Automated Cleanup via Git Hooks

You can automate the deletion of these problematic refs by adding a post-command hook or a simple alias to your Git configuration. This ensures that every time you perform a Git action, the "bad" refs are cleared:

• Create an Alias: Run git config --global alias.cleancodex "!git for-each-ref --format='delete %(refname)' refs/codex | git update-ref --stdin"

• Now, simply typing git cleancodex in any terminal will fix Sourcetree immediately.

2. Use the Sourcetree Terminal

To ensure you are running the command in the correct environment, use the built-in terminal in Sourcetree:

• Click the Terminal button in the top right of the Sourcetree header.

• Paste your cleanup command there to ensure it affects the specific repository Sourcetree is currently viewing.

3. Check for Repository Corruption

If the fatal: bad object error persists even after deleting the refs, your local object database may be slightly out of sync. You can attempt to repair it by running:

• git fsck --full --strict
• If errors are found, a fresh clone of the repository is often the safest way to restore full functionality in Sourcetree

*note that this is partially AI-ed with some additional info found in the Internet. I haven't actually tested this part myself.

You can probably browse open suggestions or bugs here. I couldn't find anything related, though > but you could create a new bug/suggestion by logging in (same account as you're using here) and then create a new issue. The 
Sourcetree team tends to look at those more than forums here. 👀
Btw, you've already got a good basis here in the forums to pretty much copy and paste this into new bug/suggestion.

Cheers,
Tobi

[添喜黄]

Thanks Tobi.

I have created an Atlassian issue for this now, since it looks more like a SourceTree compatibility issue with non-standard refs than a normal repository problem.

[Tomislav Tobijas]

Great! Can you maybe share the ticket link here as well?

[添喜黄]

ticket link: https://jira.atlassian.com/browse/SRCTREEWIN-14733

[Darcy Leo]

This is an interesting issue. It looks like the problem may be related to how SourceTree is detecting branches through the configured Git version or repository settings. Checking the Git configuration, refreshing the repository, and testing with the embedded/system Git version could help identify the cause. It would also be useful to confirm whether the branches are visible through the command line using git branch to isolate whether it is a SourceTree UI issue.

[添喜黄]

I tested with SourceTree Embedded Git as suggested, but the issue still happens.