How to Blur GitHub During Screen Sharing: Protect API Keys, Repos, and Code

Short answer

Developers share GitHub during code reviews and pair programming. Learn how to blur API keys, environment variables, private repo names, and sensitive code.

Direct answer

developers share github during code reviews and pair programming. learn how to blur api keys, environment variables, private repo names, and sensitive code and follow the step-by-step approach in this guide.

TL;DR: Before sharing your GitHub screen, blur API keys and tokens visible in code or settings, environment variable values in .env files, private repository names in the sidebar, organization-level details, Actions secrets pages, and commit messages containing internal references. ContextBlur lets you click each sensitive element to hide it -- blurs persist across refreshes so your secrets stay hidden throughout the entire session.

---

Why GitHub Screen Sharing Is a Security Risk

Developers share GitHub screens constantly. Code reviews, pair programming sessions, sprint demos, onboarding walkthroughs, and incident post-mortems all involve pulling up GitHub in front of other people. The problem is that GitHub surfaces sensitive data in almost every view.

A repository page shows the organization name, private repo names in the sidebar, and the full contents of any file you open. Settings pages display webhook URLs, deploy keys, and Actions secrets. Even a simple commit history can reveal internal project codenames, customer names in bug descriptions, or infrastructure details in branch names.

This is not a hypothetical risk. Leaked API keys from screen recordings and shared screenshots are a well-documented security best practice concern. A single frame from a recorded pair programming session can expose a token that grants access to production infrastructure.

Why GitHub's Built-In Features Are Not Enough

GitHub does have secret scanning, which detects known token patterns in committed code and alerts repository administrators. But secret scanning is a detection tool -- it notifies you after a secret has been committed. It does nothing to prevent that secret from being visible during a live screen share.

GitHub also offers fine-grained personal access tokens and repository-level permissions. These are access control measures. They determine who can read or write to a repository. They do not blur or hide data on your screen when you are sharing it with someone who should not see certain details.

For developer workflows that involve regular screen sharing, you need a tool that works at the visual layer -- hiding elements on the page without modifying the underlying data.

What to Blur in GitHub

Before starting a screen share, review the GitHub interface for these sensitive elements:

• API keys and tokens in code -- any file containing hardcoded credentials, even in example configs
• Environment variable values -- .env file contents displayed in the code viewer
• Settings > Secrets and Variables -- the Actions secrets page shows secret names (values are hidden by default, but names can be revealing)
• Private repository names -- the left sidebar and repository dropdown list all repos you have access to
• Organization name and details -- the org name in the header, member lists, and billing pages
• Commit messages with internal references -- messages containing ticket numbers, customer names, or project codenames
• Webhook URLs -- displayed in Settings > Webhooks, often containing authentication tokens
• Deploy key fingerprints -- in Settings > Deploy keys
• Branch names -- branches named after customers, internal projects, or incident IDs
• Issue and PR titles -- may reference customers, internal systems, or security vulnerabilities
• Contributor email addresses -- visible in commit details and contributor profiles

The specific elements you need to blur depend on your audience. A code review with your direct team may only require hiding the sidebar repo list. A demo for an external client should blur everything that reveals your internal infrastructure.

Step-by-Step: Blurring GitHub with ContextBlur

Follow these steps to prepare your GitHub screen for sharing. The setup takes about 90 seconds for a typical session.

1. Navigate to your starting page. Open the GitHub repository, file, or settings page you plan to show during the call. Position the page exactly as your audience will see it.

2. Activate ContextBlur. Press Ctrl+Shift+B (or Cmd+Shift+B on Mac) to enter blur mode. You can also click the ContextBlur extension icon in your Chrome toolbar. The cursor will change to indicate selection mode.

3. Blur the repository sidebar. If the left sidebar shows a list of your recent or pinned repositories, click on each repo name you want to hide. If you want to hide the entire list, click the sidebar container element.

4. Blur the organization name. Click on your organization name wherever it appears -- in the header navigation, the repository path, or the org profile section.

5. Blur sensitive code. If you have a file open that contains API keys, tokens, or environment variables, click on the specific code block or line containing the secret. For .env files, you may want to blur individual value fields while leaving the variable names visible.

6. Blur commit messages. In the commit history view, click on any commit message that contains internal references, customer names, or project codenames.

7. Blur the Settings pages. If you plan to show repository settings, navigate to Settings > Secrets and Variables > Actions and blur the secret names. Do the same for Webhooks and Deploy keys.

8. Blur issue and PR titles. In the Issues or Pull Requests tab, click on any titles that reference sensitive information.

9. Exit blur mode. Press Ctrl+Shift+B again or click the extension icon. Your blurs are locked in place and will persist across page refreshes.

10. Test your setup. Scroll through the pages you plan to share and verify that all sensitive elements are covered. Open your screen sharing tool and confirm the blurs are visible in the shared view.

Navigating Between Files During Code Review

Code reviews often involve jumping between multiple files. ContextBlur stores blur rules per page URL, so blurs you apply to repo/blob/main/config.py will remain when you navigate away and come back. However, if you open a new file you have not pre-blurred, you will need to blur any sensitive elements in that file on the fly.

A practical strategy: before the code review, open each file you plan to discuss in a separate browser tab. Apply blurs to all tabs. Then during the review, switch between pre-blurred tabs rather than navigating within a single tab.

Common GitHub Screen Sharing Scenarios

Code Reviews

The most frequent GitHub screen sharing scenario. You are walking a reviewer through your changes. Blur: the sidebar repo list (it shows other projects), any hardcoded credentials in the diff, commit messages referencing internal tickets, and the organization name if the reviewer is external. Follow a screen sharing checklist to make sure nothing is missed.

Pair Programming Sessions

You are sharing your screen while coding with a colleague. The risk here is that you may open unexpected files or navigate to pages you did not plan to show. Blur the repo sidebar and organization details as a baseline. For any file containing secrets, blur the values before opening them on the shared screen.

In AI-assisted pair sessions (Cursor/Windsurf/Bolt/Replit), this risk increases because context switching is faster and includes more dashboard hops. Keep a dedicated vibe coding checklist and secure your Cursor screen-sharing flow.

Sprint Demos and Stakeholder Presentations

Showing progress to product managers, executives, or clients. These audiences do not need to see repository internals. Blur: all repo names except the one being demoed, the organization name, contributor lists, and any open issues or PRs that reference other projects.

Onboarding New Team Members

Walking a new hire through the codebase. You may want to show the general structure while hiding credentials and secrets. Blur: all API keys, tokens, .env values, Actions secrets, and webhook URLs. Leave the code structure and documentation visible. This is a key part of building developer-friendly onboarding flows.

Auto-Detecting Sensitive Patterns with ContextBlur Pro

GitHub pages can contain email addresses, API keys, and other sensitive patterns scattered throughout code files, commit messages, and issue comments. ContextBlur Pro ($15/year) adds automatic detection for:

• Email addresses -- in code comments, commit metadata, contributor profiles, and issue threads
• Phone numbers -- occasionally found in code comments, README files, or issue descriptions
• Credit card numbers -- rare in GitHub but possible in test data files or issue reports
• SSN patterns -- found in test fixtures or configuration files in healthcare and financial repos

The auto-detect feature scans the visible page and applies blurs without requiring you to click each element individually. This is particularly useful for code files where a single page might contain dozens of email addresses in import headers, license blocks, or author annotations.

For teams working with cloud infrastructure, the combination of GitHub secret scanning (for committed credentials) and ContextBlur's visual blurring (for screen sharing) provides defense at both layers -- the repository level and the presentation level.

Tips for Developer Teams

Establish a team screen sharing protocol. Define which elements developers should blur for internal versus external screen shares. Include this in your screen sharing security documentation alongside your existing code review guidelines.

Blur before you share, never during. Setting up blurs while your screen is already visible to others defeats the purpose. Take 90 seconds before the call to prepare your views.

Use separate browser profiles. If you frequently switch between personal and work GitHub accounts, use separate Chrome profiles. This prevents your personal repos from appearing in autocomplete or sidebar suggestions during work screen shares.

Review your commit messages. Even with blurring, develop the habit of writing commit messages that do not contain customer names, internal codenames, or infrastructure details. This reduces your blurring workload and improves security at the source.

---

Keep Your Code and Secrets Hidden During Every Screen Share

GitHub is designed to surface information -- repository names, code contents, commit history, and settings are all meant to be visible to authorized users. But during a screen share, your audience may include people who should not see all of that information.

ContextBlur gives you precise control over what is visible and what is hidden. Set up your blurs in 90 seconds, keep them persistent across navigation, and let auto-detect catch the patterns you might miss.

Working mostly in editor shares instead of browser tabs? Install via VS Code, check every platform on downloads, and review feature limits on pricing.