Shell Environment
The Shell environment page sits under Toolchain in the sidebar, next to the Node.js Manager. The two answer one question between them: Node.js Manager covers the runtime Corral installs for you, and this page covers everything else your projects need to find — pnpm, bun, python3, a linter, whatever your dev command shells out to.
It makes one comparison and stops there: what your projects can reach, versus what they would reach if Corral had never read your shell.
Why the page exists
Corral does not hand your dev server the environment Corral itself is running in. It reads your login shell once — <shell> -i -l, with the shell taken from your account’s passwd entry rather than $SHELL — and composes every child process’s environment from what that produced.
That read is doing real work. A process macOS launches at login gets a handful of system directories; a process you start from a terminal gets your whole PATH. Without the read, whether Corral could find your Homebrew pnpm would depend on how Corral itself happened to start. This page is where you check that the read worked.
The headline
At the top, an eyebrow naming the state, a headline with the number in it, and a sentence explaining the difference:
Captured from your shell Your projects can reach 47 directories. Of those, 31 came from your login shell — marked below. Corral itself was started with 16; without that read, those are all your projects would get.
When the read has not happened or did not work, you get a different sentence rather than the same one with a smaller number — because “your projects can reach 16 directories” reads like a fact about your machine, when it is really a fact about what Corral fell back to:
Could not read your shell Your projects get the 16 directories Corral itself was started with.
The states
| Eyebrow | What happened | Button |
|---|---|---|
| Captured from your shell | The read succeeded | Re-read |
| Could not read your shell | The read was attempted and failed, or your account has no runnable login shell | Try again |
| Not read yet | Corral has not read it yet — it will on its next start | Read now |
If your account’s passwd entry names no runnable shell, Corral says so plainly and does not promise the button will help: that remedy is outside Corral.
PATH, in order
One list, not two — with the first-match-wins ordering the system actually uses, and each entry marked for where it came from:
- from your shell — the read added this
- also in the daemon — Corral already had it
A legend under the list counts each. Two separate lists would have left you doing the diff yourself, which is the entire question the page exists to answer.
Disclosures
Three collapsible sections below:
- What the daemon was started with — the raw
PATHCorral’s own process has, for comparison. - Where this came from — the shell startup files that were read. A file that has been edited since Corral read it is flagged changed since Corral read it; one that does not exist is marked absent. When anything is flagged, an amber note at the top tells you the capture is stale and worth re-reading.
- Variables your shell sets — the variable names your login shell defines, as chips. Names only: Corral never sends a variable’s value out of the daemon, because a login shell’s environment routinely holds API tokens. Shell bookkeeping variables are listed separately as hidden, and any variable set in both places with different values is called out.
What the page will not tell you
It does not say how Corral was started. Corral cannot see that: the environment it was launched with looks one way under launchd and another when you run corral daemon start in a terminal, and nothing distinguishes them after the fact. Any sentence naming a launch route would be true on one and false on the other, so the page does not write one.
Elsewhere
corral doctorreports the same capture from the command line.- If a tool your project needs is missing from the list, the fix is in your shell’s startup files — then press Re-read.