Microsoft Teams shows microphone denied on macOS despite microphone listed as allowed

Environment

MacBook Pro running macOS 13.5 (Ventura), Microsoft Teams (Apple-silicon native) version 1.6.x installed from company package; user account is standard (non-admin). System Settings > Privacy & Security shows 'Microphone' access granted to Microsoft Teams and the Teams helper processes.

Symptoms

When joining a Teams call the participant list shows the microphone icon disabled and Teams displays 'Microphone not detected' or shows no input level. Native Voice Memos records audio fine. Reinstalling Teams does not help. Restarting Teams with microphone permission toggled briefly shows different behaviors (sometimes shows permissions dialog, sometimes not).

Observations

Console logs include macOS TCC (Transparency Consent Control) messages indicating Teams has access. However, system log shows 'kTCC: denying request to access device' for a process named from a helper binary inside the Teams app bundle with a different team identifier. lsof shows /dev/snd-like devices are not present on macOS (use CoreAudio). Running Teams from Terminal shows no additional errors. A new test user account on the same machine runs Teams and sees the microphone working correctly, suggesting the problem is scoped to the original user's profile.

Already attempted

Tried toggling microphone access off and back on in System Settings; rebooted machine; removed Teams preference files from ~/Library/Preferences and ~/Library/Application Support/Teams; flushed TCC database using tccutil reset Microphone com.microsoft.teams (tccutil reports success but behavior unchanged). Created a fresh user account where Teams works, confirming machine-level services and hardware are functional.

Question

What user-specific artifacts or TCC database inconsistencies can cause macOS to deny microphone access to an app even when System Settings shows it as allowed, and what reversible steps can safely restore microphone access for the affected user without deleting unrelated data?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Per-user TCC database contains stale or conflicting entries for Teams helper processes (different binary path or team ID) causing denial for the helper that captures audio. 90%

Teams helper binary was replaced or updated and its code signature or team identifier changed, causing TCC to not apply the existing permission grant to the helper process. 80%

Corrupt preference files or sandbox container entries for Teams in the user's ~/Library prevent proper device access. 40%

Summary

Because Teams works under a fresh user account and hardware is confirmed working, the root cause is likely a user-scoped TCC permissions corruption, a mismatch in code-signing/team identifier for one of Teams' helper binaries causing TCC to treat it as a different app, or leftover per-user app artifacts referencing an old bundle ID. Recreating or repairing TCC entries for the exact binary identity is required; blind resets of the full TCC database are risky and require user re-consent for all apps.

Suggested Fixes

Diagnostic step 1

Export current TCC microphone entries for backup: sudo sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db .tables (note: path and access require care). Use tccutil reset Microphone com.microsoft.teams to force re-consent for Teams; verify helper processes match the bundle ID that requested access.

Diagnostic step 2

Compare the code signature team identifier of the Teams main binary and any helpers (codesign -dv --verbose=4 /Applications/Microsoft\ Teams.app) to the TCC entries to detect mismatches.

Diagnostic step 3

Temporarily create a new macOS user and migrate only essential application preferences to the new account to see if a full user-profile repair is needed; avoid wholesale deletion of the original account until recovery is validated.