[Bug]: Desktop becomes unresponsive after activating microphone on macOS arm64 (0.1.9)

Aberta
#34,941 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
electron, typescript

Direção de pesquisa

Start in apps/desktop and inspect the voice input path, especially the installed bundle’s useEnvironmentSpeechInput-C8qzzg6U.js, which sequences backend preparation, microphone access, and AudioWorklet setup. Try to identify which startup stage can remain pending and how it can be reproduced; the report does not establish a root cause or name source files or tests. Done means isolating the freeze and restoring responsiveness or showing an actionable error, with a reproducible check.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

T3 desktop becomes unresponsive after activating microphone (macOS arm64, 0.1.9)

Area

apps/desktop (voice input)

Steps to reproduce (user-reported; not independently reproduced)

  1. Use the T3 Code desktop app on an Apple Silicon iMac.
  2. Activate microphone/voice input.
  3. The user reports that T3 becomes unresponsive immediately afterwards.

This incident was reported on 2026-11-12 around 07:51 UTC. The exact click time, selected audio device, voice destination/provider, duration, and whether the entire window or only the voice/composer controls stopped responding are not established. No deliberate reproduction or microphone recording was performed during diagnosis.

Expected behavior

Voice input starts, or shows an actionable error; the app remains responsive and the operation can be cancelled.

Actual behavior / impact

User-reported freeze after enabling the microphone, interrupting interaction. Root cause is not established.

Version and environment

  • T3 Code (Beta) 0.1.9, packaged commit 24e77473ecf4.
  • macOS 15.3.1 (24D70), arm64.
  • Bundled Electron framework CFBundleVersion: 44.10.1.
  • Main and renderer processes had been running since approximately 23:03 local time the previous evening, about 9 hours 49 minutes at sampling.
  • Approximately 44 GiB free on the data volume at diagnosis.

Read-only observations

  • Main, renderer and backend processes were still alive. Server traces continued to be written. This does not prove that the UI or voice operation was responsive.
  • No T3/Electron-named crash or hang report was found in the user or system DiagnosticReports directories.
  • Two-second samples of the existing main and renderer processes, taken approximately 07:52:44 and 07:52:47 UTC, mainly show event-loop waits rather than a CPU-bound loop. They do not establish a deadlock or exclude an unresolved asynchronous operation.
  • Sanitized main-thread stack excerpt: NSApplication run -> CFRunLoopRunSpecific -> __CFRunLoopServiceMachPort -> mach_msg -> mach_msg2_trap.
  • Renderer main thread: 1482 of 1483 sampled paths end in mach_msg2_trap; stripped Electron symbols limit interpretation.
  • Desktop trace window 07:45–07:52 UTC contains 100 spans and zero Failure exits. Server failures exist, but no causal link to voice was established. No voice-specific runtime error was found in the inspected trace records; there is no confirmed error message to quote.

Voice path inspected in the installed bundle

useEnvironmentSpeechInput-C8qzzg6U.js prepares the transcription backend, then uses navigator.mediaDevices.getUserMedia, AudioContext, audioWorklet.addModule, and AudioWorkletNode("t3-pcm-capture") for capture. The startup path sets phase preparing before awaiting preparation/permission/capture.

Hypothesis only: an unresolved startup promise (backend preparation, media access, or AudioWorklet initialization) could leave voice controls pending without a busy native main thread. In the inspected getUserMedia wrapper, cancellation is wired through AbortSignal, but no explicit local timeout is visible. This is a suggested investigation point, not a demonstrated cause or a proposed confirmed fix. The selected backend and the precise stalled stage remain unknown.

Previous report / duplicate search

The account's confirmed previous report in this repository is #33235 (CLI delegated subagents), which is unrelated. Searches of authored/involved issues and microphone/freeze/dictation-hang issues did not identify a matching earlier microphone-freeze report. The user recalls an earlier T3 report; its identity could not be established, so this is not asserted to be a regression of a particular issue.

Raw logs, process sample files, conversation content, audio, user filesystem paths, credentials and device identifiers are intentionally not attached. No app restart/termination, permission change or configuration change was performed.

Linguagem predominante
TypeScript
Estrelas
24.8k
Forks
6.4k
Merge médio
4h 16min
PRs com merge (30d)
352

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de pingdotgg/t3code

Todas as issues de pingdotgg/t3code

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.