# \[Bug\]: "turn/setPermissionMode failed" masks provider CLI startup death — macOS TCC EPERM kills both Claude and Codex when project is in a protected folder · Issue \#5943 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/5943)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: backlog

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/5943)

---

### Before submitting

- [x] I searched existing issues and did not find a duplicate.
- [x] I included enough detail to reproduce or investigate the problem.

### Area

apps/server

### Steps to reproduce

On macOS:

1. Have a project inside a TCC-protected folder (`~/Desktop/...`, `~/Documents/...`, `~/Downloads/...`)
2. Remove T3 Code's Files-and-Folders permission — or simply delete + re-download the app, which can invalidate the existing grant **silently** (macOS shows no re-prompt)
3. Send any prompt in any thread, with any provider

### Expected behavior

1. When the provider CLI process exits before/during the control-protocol handshake, the UI error should surface the child's **stderr and exit code**, not the name of the first RPC that happened to fail against the dead process.
2. On macOS, when the spawn fails with `EPERM` and the project path is under Desktop/Documents/Downloads, show actionable guidance ("grant T3 Code access in System Settings → Privacy & Security → Files and Folders").

### Actual behavior

- Claude threads fail with `Provider turn start failed — turn/setPermissionMode failed` and a "Claude runtime stream failed." banner
- Codex threads fail with `ProviderAdapterProcessError: ... Codex App Server process exited with code 1`
- Neither error mentions the real cause. The truth is only in `~/.t3/userdata/logs/server.trace.ndjson`:

```
[cause]: Error: Claude Code process exited with code 1.
stderr: error: An internal error occurred (EPERM)
```

The spawned CLI dies instantly on startup (macOS TCC denies file access under the protected folder for child processes of the app), and the first control request (`set_permission_mode`) fails against a dead process — so the user-facing error blames permission *modes*. This sends users down entirely the wrong debugging path (reinstalling the app, changing the permission-mode dropdown, etc.), and I suspect some existing reports of this error tag (e.g. #4495) are actually this failure mode misdiagnosed.

Verified during diagnosis: the same pinned CLI binary, run from Terminal in the same project directory, works perfectly — including every `set_permission_mode` value (`default`, `acceptEdits`, `plan`, `bypassPermissions`, `auto`) sent over the stream-json control protocol. The failure only occurs when the CLI is spawned as a child of T3 Code without the folder grant.

### Impact

Major degradation or frequent failure

### Version or commit

0.0.32

### Environment

macOS (Darwin 25.5), T3 Code 0.0.32 desktop app, claude CLI 2.1.223 (SDK-pinned, @anthropic-ai/claude-agent-sdk 0.3.223), codex-cli 0.147.0. Both providers fail identically; both work standalone from Terminal.

### Workaround

```
tccutil reset All com.t3tools.t3code
```

then relaunch the app and re-grant folder access when prompted. Fixes both providers immediately.