macOS seatbelt sandbox appears to break sourcekitd/sourcekit-lsp (SOURCEKITD FATAL ERROR: Service is invalid)

What version of Codex CLI is running?

codex-cli 0.142.5

What subscription do you have?

I don't have a subscription.

Which model were you using?

_No response_

What platform is your computer?

_No response_

What terminal emulator and version are you using (if applicable)?

_No response_

Codex doctor report

What issue are you seeing?

sourcekit-lsp fails with "SOURCEKITD FATAL ERROR: Service is invalid" inside macOS seatbelt sandbox

Summary

sourcekit-lsp fails to communicate with sourcekitd when running inside the macOS sandbox used by local CLI agents (Codex/TraeX-style environments).

The observed error is:

SOURCEKITD FATAL ERROR: Service is invalid

````

At a higher level, clients may observe the LSP process terminating unexpectedly.

This appears to be related to the macOS seatbelt sandbox policy rather than an LSP protocol issue. The current sandbox policy allows process execution and process spawning, but may block part of the launchd/XPC/mach service communication path required by `sourcekitd`.

## Environment

- OS: macOS
- Tool: `sourcekit-lsp`
- Repro surface: local CLI sandbox execution
- Related code:
  - `codex-rs/sandboxing/src/seatbelt.rs`
  - `codex-rs/sandboxing/src/seatbelt_base_policy.sbpl`
  - `codex-rs/sandboxing/src/seatbelt_network_policy.sbpl`

I can provide exact macOS/Xcode versions if needed.

---

## Why this may be sandbox-related

I inspected the current macOS seatbelt policy:

* `codex-rs/sandboxing/src/seatbelt.rs`
* `codex-rs/sandboxing/src/seatbelt_base_policy.sbpl`
* `codex-rs/sandboxing/src/seatbelt_network_policy.sbpl`

Observations:

* The policy starts with:

(deny default)

* It explicitly allows:

(allow process-exec)
(allow process-fork)

Therefore this does not appear to be a general process spawning restriction.

* The policy contains a limited mach service allowlist.
* The current policy does not appear to allow the job creation path required by `sourcekitd`.

My current hypothesis is that `sourcekitd` requires additional sandbox permissions for launchd/XPC/mach service communication.

---

## Expected behavior

`sourcekit-lsp debug run-sourcekitd-request --request-file ...` should work correctly when Swift tooling is expected to be supported inside the macOS sandbox.

The sandbox policy should allow the required sourcekitd communication path.

---

## Proposed solution

Add the required permission for sourcekitd communication, likely including:

(allow job-creation)

and any required mach service lookup permissions used by sourcekitd.

Alternatively, expose a supported mechanism to extend the macOS seatbelt policy for Swift tooling workflows.

I intentionally did not guess the exact mach service names because the required sandbox model should be confirmed by maintainers.


### What steps can reproduce the bug?

## Minimal reproduction

This reproduces without project indexing or editor integration.

### 1. Create request file

`req.news.yaml`

```yaml
{
  "key.request": "source.request.protocol_version"
}
````

### 2. Run sourcekit-lsp

```bash
sourcekit-lsp debug run-sourcekitd-request --request-file req.news.yaml

3. Actual result

SOURCEKITD FATAL ERROR: Service is invalid

This suggests the failure happens at the sourcekitd communication layer itself, rather than higher-level LSP functionality such as diagnostics or indexing.

---

What is the expected behavior?

_No response_

Additional information

_No response_