# 2026-09-12 — Non-Go dependencies: none

A single question, answered; no code touched, nothing in flight.

**Question**: does turbo-core depend on any non-Go library?

**Finding**: no, and here is the evidence so the next session need not re-run it.

- `go.mod`: three direct (`tcell/v2`, `BurntSushi/toml`, `golang.org/x/sys`), five indirect (`gdamore/encoding`, `go-colorful`, `uniseg`, `x/term`, `x/text`). All pure Go.
- `grep -rn '"C"' --include='*.go' .` → nothing. No cgo in this repository.
- `CGO_ENABLED=0 go build ./...` → OK. That is the decisive check: it proves nothing in the graph *requires* cgo.
- Scanning each module in `GOMODCACHE` for `*.c`/`*.h`: only `x/sys` has any — `cpu/cpu_gccgo_x86.c` and `unix/gccgo_c.c`. Both are for the **gccgo** compiler and are not built by the standard `gc` toolchain. Do not report these as a native dependency.
- `net` shows up in `go list -deps` only through `lsp/fakeserver_test.go` and `app/fakelsp_test.go`. Test-only.

**The distinction worth keeping**: no *link-time* native dependency, but the running editor does exec external *binaries* — `/bin/sh` (`tools/run.go:19`, `app/toolchain.go:35`) for terminal windows and the tools menu, and the profile's LSP server command (`lsp/server.go:92`, `profile.Profile.Command`). If the question ever comes back phrased as "what does a user need installed", that is the answer; "what does it link against" is nothing.

**Consequence**: a statically linked, cross-compilable binary with no C toolchain needed.

**Next steps**: none opened by this session. `summary.md`'s "Two direct dependencies plus one" decision (line ~94) still holds and was left byte-for-byte alone.