[Feature]: T3 never requests macOS microphone/camera permission, so it can never be granted - blocks all voice/vision MCP tooling

[simonseifert]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/desktop

Problem or use case

T3 Code can never obtain macOS microphone or camera permission, which blocks every voice or vision tool run from inside it.

macOS grants these per application. When any child process of T3 requests audio, TCC resolves the responsible app to T3 Code, finds no grant, and returns digital silence — no error, no prompt, just a stream of zeros. The same happens for the camera.

The catch is that T3 never appears in System Settings > Privacy & Security > Microphone at all, because an app only gets listed once it has requested the permission. Nothing in T3 ever does. And those panes have no "+" button, so the user cannot add it manually either.

The result is a permanent dead end: the permission can't be granted because it was never requested, and it's never requested because there's no feature that asks.

Evidence

Info.plist already declares both usage strings, so the intent is there:

NSCameraUsageDescription      = "This app needs access to the camera"
NSMicrophoneUsageDescription  = "This app needs access to the microphone"

Every capture path from inside T3 returns silence. Tested on macOS 15.5, Apple Silicon, T3 Code Nightly 0.0.34-nightly.20260816.1110:

Attempt	Result
ffmpeg -f avfoundation -i ":1" (built-in mic)	mean_volume: -91.0 dB, max_volume: -91.0 dB (digital silence)
Same via iPhone Continuity mic	-91.0 dB
Python + sounddevice (voicemode's own venv)	peak=0.0000 rms=0.0000
tccutil reset Microphone com.t3tools.t3code then retry	still -91.0 dB, no prompt appears
After a full app restart	unchanged
Same commands run from Ghostty (which holds a grant)	works

Mean volume exactly equal to max volume at -91dB is the signature of a zero-filled buffer, not a quiet room.

The camera behaves identically, which also blocks screen/vision tooling.

Why this matters

It blocks an entire category of MCP tooling. Concretely, VoiceMode — voice conversations with the agent — cannot work inside T3 no matter how it's configured, because its STT capture is silent. The only workaround is to abandon the T3 UI and run the same agent in Ghostty or Terminal, which do have grants.

Any future MCP server doing audio, video, or screen capture will hit the identical wall.

Proposed solution

Trigger the request once, from the app. A single call to the system permission API — behind a settings toggle, a first-run prompt, or lazily the first time a tool needs it — makes macOS show the dialog and adds T3 to the Privacy list. After that, every child process inherits the grant and everything works.

Something as small as Settings > Permissions > "Enable microphone access" and the same for camera would do it. The usage strings are already in Info.plist, so nothing else is needed.

Smallest useful scope

One user-triggerable action anywhere in the UI that causes T3 to request microphone (and ideally camera) access, so the app registers in System Settings.

Alternatives considered

• Manual add in System Settings — impossible, those panes have no "+".
• tccutil reset — only clears state; without a request, no prompt follows.
• Granting the child binary — doesn't work. TCC resolves to the responsible app, not the binary. A python3.12 with its own grant (earned under another terminal) still gets silence when spawned by T3.
• Run the agent in Ghostty instead — works, but means giving up T3 for any voice work.

Risks or tradeoffs

Requesting a permission the user hasn't asked for is unwelcome, so it should be user-initiated rather than shown at startup. A toggle in settings, or a prompt at the moment a tool first needs audio, avoids that.

Contribution

• I would be open to helping implement this.