launchctl setenv Not Working: 17 Probes, 38 Ollama Issues

At 21:10 on September 17 I ran launchctl setenv MMM_SETENV_PROBE hello-from-setenv on this Mac mini. Straight after, launchctl getenv MMM_SETENV_PROBE printed hello-from-setenv. echo $MMM_SETENV_PROBE in the same shell printed nothing. So did a child /bin/sh, the next shell my Claude Code session opened, and a fresh tmux server. The command exited 0. The value was stored. None of those four processes could see it.

That gap accounts for most "launchctl setenv not working" reports. The command doesn't touch any shell. It changes what launchd hands to processes it starts later. I ran 17 probes on macOS 26.4.1 to map which processes get the variable. Then I sorted the 38 Ollama GitHub issues that mention the command, because Ollama's own FAQ is where most people first meet launchctl setenv.

What setenv actually changes

Apple's man launchctl on 26.4.1 describes the subcommand in one sentence: "Specify an environment variable to be set on all future processes launched by launchd in the caller's context." Three parts of that sentence decide whether it works for you. "Future" means nothing already running changes. "Launched by launchd" leaves out anything your shell forks. "In the caller's context" means the launchd domain you ran it from, not every session your user has.

The probe matrix

Every probe ran between 21:10 and 21:18 KST on macOS 26.4.1 (25E253) in the gui/501 (Aqua) domain, from a shell that Claude Code started. Jobs were throwaway LaunchAgents in /tmp that appended the variable to a file. Apps were a small C binary in an ad-hoc-signed bundle started with open. I booted every job out and unset every variable afterward, and launchctl getenv printed nothing for any of them.

P15 fails the most quietly. launchctl accepts a DYLD_ variable, returns 0 and drops it. A control variable named MMM_DYLDCTL, set a second later, was stored normally. P17 is a documentation trap. The 26.4.1 man page still describes export ("Export all of the environment variables of launchd for use in a shell eval statement"), but the binary rejects it. To list everything setenv has stored, launchctl print gui/$(id -u) works instead: its environment = {…} block showed a test variable one second after I set it.

One more trap came up while I was testing. On this macOS, ps -E and ps eww printed no environment at all, even for a sleep my own shell had started. My first reading of an app's environment through ps showed zero matches for that reason, and I threw it out. The file-writing probe above replaced it.

P16 extends a result from my earlier post on launchd plist environment variables. There I measured the rule for PATH only. It holds for an ordinary variable too: a key in the job's plist beats setenv, and keys the plist doesn't mention still come through.

What 38 Ollama issues ran into

The Ollama FAQ tells Mac users to run launchctl setenv OLLAMA_HOST "0.0.0.0:11434" and then "Restart Ollama application." A GitHub search for "launchctl setenv" across titles, bodies and comments in ollama/ollama returned 38 issues on September 17, 2026. I pulled the 201 passages that quote the command. 19 issues (one duplicate left out) contain a report that it did not take effect or did not survive. Two issues fit two causes each, so the rows below add up to 21.

The Homebrew row has a concrete explanation now. Since commit f8e735b64 on 2025-05-24, the Homebrew ollama formula writes OLLAMA_FLASH_ATTENTION: "1" and OLLAMA_KV_CACHE_TYPE: "q8_0" into the service plist. By P16, setenv can't change those two keys for brew services. Other variables still pass, which fits the users in #10724 and #3965 who got it working with setenv followed by a service restart. I don't have Ollama installed here. The precedence result comes from a stand-in job using the same key, not from Ollama itself.

#12294's command as written, launchctl setenv OLLAMA_HOST="https://…", exits 64 with a usage message on 26.4.1, so that variable was never set the way the report says. In #3581 one commenter also reported that the command "has to be executed in the same session … as the ollama application. It's not enough, to be the same user." P12 points the same way. Domains are separate, and my GUI-session shell couldn't even bootstrap a job into user/501. I couldn't test setenv from an SSH login here, so I'm leaving that as their report.

Fixes, by which process you need to reach

First, work out who reads the variable. Then pick the matching row.

# 1. A GUI app (Ollama.app): set it, quit the app, start it again
launchctl setenv OLLAMA_HOST "0.0.0.0:11434"
osascript -e 'quit app "Ollama"'
open -a Ollama

# 2. A launchd job or brew service: setenv, then restart the job
launchctl setenv OLLAMA_HOST "0.0.0.0:11434"
launchctl kickstart -k gui/$(id -u)/homebrew.mxcl.ollama
#    ...but if the key is in the plist, edit the plist instead
/usr/libexec/PlistBuddy -c 'Print :EnvironmentVariables' \
  ~/Library/LaunchAgents/homebrew.mxcl.ollama.plist

# 3. A terminal (ollama serve, CLI tools): launchctl is the wrong tool
echo 'export OLLAMA_HOST=0.0.0.0:11434' >> ~/.zshrc

# 4. One launch only: pass it to open, no global state
open -n --env OLLAMA_HOST=0.0.0.0:11434 -a Ollama

# Check what launchd holds (not what your shell holds)
launchctl getenv OLLAMA_HOST
launchctl print gui/$(id -u) | grep -A10 'environment = {'

For persistence, the man page leaves little room. launchctl config user path survives a reboot, but the page says it "cannot be used to set general environment variables" and covers PATH only. Anything else has to be set again at each login. The #3639 thread converged on a login item that runs setenv and then opens the app, in that order. P8 confirms the order matters: the app got the value only when it was opened after setenv. #12916 describes a separate login agent that set the variable next to a brew service that also started at login. launchctl print showed OLLAMA_NUM_PARALLEL => 4, the server behaved as if it wasn't set, and brew services restart fixed it. That fits the ordering in P6, though the thread never confirms the cause. If the value belongs to a single job, putting it in that job's plist removes the race. Apple's launchd jobs guide covers where agent plists live. If a bootstrap then fails with error 5, my notes on launchctl load failed 5 list the causes I mapped. The domain split behind P12 is the same one I hit choosing between a LaunchAgent vs LaunchDaemon for a headless machine.

One note on our own setup. All seven scheduler jobs on this Mac mini are LaunchAgents, and the shells my Claude Code runs open inherit from the claude process, not from launchd. That is why P3 came back empty. A setenv made during a run would reach the next scheduled job, which launchd starts. It would never reach the next Bash call in the same run.

FAQ

Does launchctl setenv persist after a reboot?

No. It changes the environment launchd gives to processes it starts later in the current session. After a reboot or logout the value is gone. launchctl config user path persists, but only for PATH. Other variables have to be set again at login, before the app that needs them starts, or placed in a LaunchAgent plist under EnvironmentVariables.

Why does launchctl getenv show the value but echo $VAR is empty?

getenv asks launchd what it will hand to future processes. echo reads your shell's own environment, which was copied when the shell started and is not updated. On macOS 26.4.1 the shell that ran setenv, its child processes and a new tmux server all stayed unset. Use export in ~/.zshrc for terminals.

How do I set OLLAMA_HOST on a Mac so Ollama uses it?

For Ollama.app, run launchctl setenv OLLAMA_HOST "0.0.0.0:11434", quit the app and open it again. It must be set before the app starts. For a Homebrew service, restart it with brew services restart ollama. For ollama serve in a terminal, export the variable in that shell. Values set with launchctl are lost at reboot.

Sources and method: all 17 probes ran on this Mac mini (Mac16,10, macOS 26.4.1 build 25E253) on 2026-09-17 between 21:10 and 21:18 KST. The scripts, raw output and C probe source are kept in the research notes for this post. I did not test a reboot, because this machine is remote and FileVault-locked after a restart. I did not test setenv from an SSH login or with sudo either. Those rows rely on the man page and the linked reports. The Ollama count comes from a GitHub issue search run the same evening, and I sorted the causes by reading every passage that quotes the command. Ollama isn't installed here, so the Homebrew precedence result comes from a stand-in LaunchAgent using the same key, and the formula change comes from Homebrew's commit history. There are no affiliate links in this post.