Summary
I am investigating a change in macOS 26.1 (Tahoe) where plain (non-bundled) executables that request screen recording access no longer appear under:
System Settings → Privacy & Security → Screen & System Audio Recording
This behavior differs from macOS Sequoia, where these executables did appear in the list and could be managed through the UI. Tahoe still prompts for permission and still allows the executable to capture the screen once permission is granted, but the executable never shows up in the UI list. This breaks user expectations and removes UI-based permission management.
To confirm the behavior, I created a small reproduction project with both:
a plain executable, and
an identical executable packaged inside an .app bundle.
Only the bundled version appears in System Settings.
Observed Behaviour
1. Plain Executable (from my reproduction project)
When running a plain executable that captures the screen:
macOS displays the normal screen-recording permission prompt.
Before granting permission: screenshots show only the desktop background.
After granting permission: screenshots capture the full display.
The executable does not appear under “Screen & System Audio Recording”.
Even when permission is granted manually (e.g., dragging the executable into the pane), the executable still does not appear, which prevents the user from modifying or revoking the permission through the UI.
If the executable is launched from inside another app (e.g., VS Code, Terminal), the parent app appears in the list instead, not the executable itself.
2. Bundled App Version (from the reproduction project)
I packaged the same code into a simple .app bundle (ScreenCaptureApp.app).
When running the app:
The same permission prompt appears.
Pre-permission screenshots show the desktop background.
Post-permission screenshots capture the full display.
The app does appear under “Screen & System Audio Recording”.
This bundle uses the same underlying executable — the only difference is packaging.
Hypothesis
macOS 26.1 (Tahoe) appears to require app bundles for an item to be shown in the Screen Recording privacy UI.
Plain executables:
still request and receive permission,
still function correctly after permission is granted,
but do not appear in the System Settings list.
This may be an intentional change, undocumented behavior, or a regression.
Reproduction Project
The reproduction project includes:
screen_capture.go A simple Go program that captures screenshots in a loop.
screen_capture_executable Plain executable built from the Go source.
ScreenCaptureApp.app/ App bundle containing the same executable.
build.sh Builds both the plain executable and the app bundle.
Permission reset and TCC testing scripts.
The project demonstrates the behavior consistently.
Steps to Reproduce
Plain Executable
Build:
./build.sh
Reset screen capture permissions:
sudo tccutil reset ScreenCapture
Run:
./screen_capture_executable
Before granting: screenshots show desktop only.
Grant permission when prompted.
After granting: full screenshots.
Executable does not appear in “Screen & System Audio Recording”.
Bundled App
Build (if not already built):
./build.sh
Reset permissions (optional):
sudo tccutil reset ScreenCapture
Run:
open ScreenCaptureApp.app
Before granting: screenshots show desktop.
After granting: full screenshots.
App bundle appears in the System Settings list.
Additional Check
I also tested launching the plain executable as a child process of another executable, similar to how some software architectures work.
Result:
Permission prompt appears
Permission can be granted
Executable still does not appear in the UI, even though TCC tracks it internally → consistent with the plain-executable behaviour.
This reinforces that only app bundles are listed.
Questions for Apple
Is the removal of plain executables from “Screen & System Audio Recording” an intentional change in macOS Tahoe?
If so, does Apple now require all screen-recording capable binaries to be packaged as .app bundles for the UI to display them?
Is there a supported method for making a plain executable (launched by a parent process) appear in the list?
If this is not intentional, what is the recommended path for reporting this as a regression?
Files
Unfortunately, I have discovered the zip file that contains my reproduction project can't be directly uploaded here.
Here is a Google Drive link instead: https://drive.google.com/file/d/1sXsr3Q0g6_UzlOIL54P5wbS7yBkpMJ7A/view?usp=sharing
Thank you for taking the time to review this. Any insight into whether this change is intentional or a regression would be very helpful.
