How to Blur GitLab During Screen Sharing (Hide Code, Secrets & Private Repos)
Reviewing an MR or a pipeline on a call? Here's how to hide private group and project names, CI/CD variables, access tokens, keys in files and diffs, and issue content in GitLab before you share your screen.
The safest way to hide code, secrets and private repositories in GitLab during a screen share is to blur the sensitive items in the page before you present — private group and project names in the sidebar and breadcrumb, values on the CI/CD Variables page, access tokens, and any keys sitting in a file or a merge-request diff. BlurFirst paints each blur into the page as real pixels, so it survives Zoom, Google Meet, Microsoft Teams, Loom, OBS and even a screenshot of the shared feed.
GitLab is a browser-based app that re-renders as you move between the repository tree, merge requests and pipelines, so lean on anchored region blurs for the fixed chrome — the left sidebar and breadcrumb that carry your group path and project name — and use element blur or Scan for individual values like a revealed CI/CD variable. Start blurring with Ctrl/⌘ ⇧ Y and keep the panic hotkey Ctrl/⌘ ⇧ H ready for a job log or diff that scrolls a secret into frame.
What GitLab shows that you didn't mean to share
- Private group and project names — the left sidebar, breadcrumb and project header carry a path like
acme-corp/billing-service, quietly disclosing your internal structure and client names. - CI/CD variables — under Settings > CI/CD > Variables, values are masked by default, but the Reveal values button prints deploy tokens, database URLs and API keys in plain text.
- Access tokens — personal, project and group tokens under Settings > Access Tokens show the token string (
glpat-…) once on creation; leaving that screen up on a call leaks it. - Secrets committed in files — a
.env, aconfig/secrets.yml, or a hard-coded key visible in the repository file tree or the blob view. - Merge-request diffs — added lines in an MR can contain keys, credentials or customer data; the diff view shows every changed line.
- Issue and epic content — descriptions and comments that name customers, quote support tickets, or paste stack traces with internal hostnames.
- Members and the repo tree — the Members page lists everyone with access and their roles, and the file tree reveals your service names and module layout.
- Pipeline job logs — CI/CD job output under Pipelines that echoes an environment variable or a value that wasn't masked correctly.
Blur GitLab step by step
- 1
Open the project and page you'll present
Navigate to the exact page before the call — the repo tree, a merge request, or the pipeline — so you never open Settings > CI/CD live with a variable revealed.
- 2
Box-blur the sidebar and breadcrumb
Drag a BlurFirst box over the left sidebar and the top breadcrumb that carry your group path and project name. As an anchored region blur it keeps covering that chrome as GitLab re-renders between pages.
- 3
Element-blur variables, tokens and diff lines
On the CI/CD Variables page, click a value to frost just it; do the same for a
glpat-token or a line in a merge-request diff. Click again to reveal if you must. - 4
Run Scan to catch keys and emails
One click runs Scan (Pro), which detects API-key and access-token patterns and email addresses locally and blurs them — useful across a diff, a job log or an issue thread. It won't treat a project path or a service name as a pattern, so box- or element-blur those yourself.
- 5
Keep panic ready for logs and diffs
If a pipeline job log or a long diff scrolls a secret into frame, press Ctrl/⌘ ⇧ H to blur the whole page instantly, then reveal only what's safe.
| Sensitive item | Where it appears | Best gesture |
|---|---|---|
| Group + project names | Sidebar, breadcrumb, header | Box-blur the chrome |
| CI/CD variable values | Settings > CI/CD > Variables | Element blur; don't click Reveal live |
Access tokens (glpat-…) | Settings > Access Tokens | Element blur, or Scan |
| Keys in files / MR diffs | Repository, merge requests | Element blur, or Scan |
| Member list + issue content | Members, Issues | Box- or element-blur per row |
Why a private repo and masked variables aren't enough
Marking a project private controls who can log in and read it; masking a CI/CD variable hides it in job logs. Neither controls what a person watching your screen sees. On a share the signed-in user is *you*, so the audience reads whatever your account can — and GitLab's own Reveal values button will print a masked variable in plain text the moment you click it. Repository permissions and variable masking gate access and logs, not the presentation layer. In-page blurring works there instead: it controls what the viewer sees, whatever your access is.
Reuse your GitLab blurs on every visit
If you demo, review MRs or run pipelines from GitLab regularly, set the structural blurs once. BlurFirst Pro's per-site auto-apply re-applies your saved boxes — the sidebar and breadcrumb — automatically each time you open gitlab.com, and they survive the app's re-render as you move between the tree, merge requests and CI/CD. The profile stores only a CSS selector for each region, never the project names, variable values or tokens inside it, so nothing sensitive is written to disk or uploaded.