Repository & Activity Tracking
Use this guide when developers see missing development activity in the Portal or the IDE shows:
- "You are working on files outside of tracked repositories for CodeTogether"
- Activities are not appearing even though the repository is configured in the CodeTogether Portal
Symptoms and what they usually mean
"You are working on files outside of tracked repositories for CodeTogether"
CodeTogether cannot match the local cloned repository to a repository configured in the CodeTogether Portal.
Common causes:
- The remote URL does not match what is configured in the Portal.
- The repository was added in the Portal under a different team/project.
- Git URL rewrite/alias rules change the effective remote URL (e.g.,
insteadOf). - The repo provider is not GitHub and URL normalization/secondary ID matching can fail more often.
Activities not appearing
This is usually caused by missing or mismatched Git email on the developer workstation (recent builds rely on Git email for membership matching).
Also note:
- If a developer has no recent commits, they may not appear active until at least one commit is synced.
Step 1 — Verify repository remote URL matches the Portal
On the developer machine, run from inside the repo:
git remote -v
git remote get-url --push origin
In the Portal:
- Confirm the repository is listed under the correct team/project
- Compare the Portal repository URL with the developer
originURL
Watch for common mismatches:
- Different host (e.g., github.com vs an enterprise Git host)
- Organization/repo name casing differences
- Redirected clone URLs
Optional: check for URL rewrite/alias rules
These can change the effective URL:
git config --global --get-regexp 'url\..*\.insteadof' || true
If the repo looks correct but still isn’t recognized
Collect the repository’s .git/config (or at least the [remote "origin"] section) and confirm:
- The
originURL matches what’s configured in the Portal - The repo points to the expected host and repository path
- No URL aliasing rules are rewriting the URL unexpectedly
Step 2 — Verify Git email is set and matches the Portal profile
On the developer machine:
git config user.email
git config --global user.email
If both are empty, the developer may appear as private and activity may not map to the correct user.
Set the email:
git config --global user.email "developer@company.com"
Confirm email matches in the Portal
In the Portal, open the developer profile and check:
- Primary email / SSO email
- Any alternate emails
The email returned by the Git commands must match at least one email on the profile.
If it does not:
- Update the Git config email to match the Portal, or
- Add the Git email as an alternate email in the Portal
Also check repo-level configuration (source of truth)
The email can be set in either location:
- Global:
~/.gitconfig - Repo-specific:
${project}/.git/config
To see where user.email is coming from:
git config --list --show-origin | grep -i user.email || true
If no user.email exists in either config, the developer will always appear as private.
Environment notes
Snapshot environments (anonymized)
Anonymized snapshots may contain placeholder users and do not include valid user emails.
In these cases, matching relies heavily on the developer machine Git configuration (user.email) and Portal profile emails.
WSL (Windows Subsystem for Linux)
If the developer uses WSL, ensure Git is configured inside WSL, not only in Windows:
# Run inside the WSL terminal
git config --global user.email
What to collect for support (minimum)
Ask for outputs from:
git remote -vgit remote get-url --push origingit config user.emailgit config --global user.emailgit config --global --get-regexp 'url\..*\.insteadof' || true
If needed, include the relevant section of the repo’s .git/config showing [remote "origin"].