Summary
make dev-install fails in a sandboxed environment with a misleading xcode-select error. Compiling actually works fine — only installing is genuinely blocked.
Environment: macOS 26.6.2, Darwin arm64, Seatbelt sandbox with redirected $HOME (/Users/sabath/sandbox/rosso-new). Agent: Claude Code / Opus 5.
Compiling: works — the error is misleading
$ make dev-install
xcode-select: error: unable to read data link at '/var/select/developer_dir', expected symbolic link (Operation not permitted)
xcode-select: error: No developer tools were found and no install could be requested
This is not a Cortex or Go problem. /usr/bin/make is itself an Xcode shim, and the sandbox blocks /var/select/, so make fails before reading a single line of the Makefile — make --version alone reproduces it.
Running the underlying go build commands directly, both binaries compile clean (abctl, and authbridge-proxy with the full profile / all 13 plugins). cgo is not required. Installing GNU make would fix this, but brew install make is also sandboxed (/opt/homebrew/Cellar read-only).
Installing: genuinely blocked
Two structural walls, neither fixable from inside the sandbox:
$HOME redirection — ~/.local/bin resolves inside the sandbox, while the real /Users/sabath/.local/bin (where the supervised binary lives) is Operation not permitted. The install lands in a copy nothing supervises.- launchd is read-only —
abctl service install --yes --restart fails with Boot-out failed: 1: Operation not permitted, so the service can't be restarted.
Workaround
Build inside the sandbox, install outside from a host shell:
cp cortex/bin/{authbridge-proxy,abctl} ~/.local/bin/ # via .new + mv -f, see Makefile
abctl service install --yes --restart
The .new-then-mv step matters: replacing a running executable in place fails with ETXTBSY.
Possible improvements
dev-install could detect the xcode-select shim failure and point at gmake, rather than surfacing a compiler error for a build that needs no compiler.- No way to query a running proxy's version — it appears only in the startup log line (
msg="authbridge-proxy starting" version=v0.7.0-rc.1). A /v1/version endpoint or abctl version subcommand would help. Note local builds report version=dev; only the release workflow stamps via -ldflags.
Summary
make dev-installfails in a sandboxed environment with a misleadingxcode-selecterror. Compiling actually works fine — only installing is genuinely blocked.Environment: macOS 26.6.2,
Darwin arm64, Seatbelt sandbox with redirected$HOME(/Users/sabath/sandbox/rosso-new). Agent: Claude Code / Opus 5.Compiling: works — the error is misleading
This is not a Cortex or Go problem.
/usr/bin/makeis itself an Xcode shim, and the sandbox blocks/var/select/, so make fails before reading a single line of the Makefile —make --versionalone reproduces it.Running the underlying
go buildcommands directly, both binaries compile clean (abctl, andauthbridge-proxywith the full profile / all 13 plugins). cgo is not required. Installing GNU make would fix this, butbrew install makeis also sandboxed (/opt/homebrew/Cellarread-only).Installing: genuinely blocked
Two structural walls, neither fixable from inside the sandbox:
$HOMEredirection —~/.local/binresolves inside the sandbox, while the real/Users/sabath/.local/bin(where the supervised binary lives) isOperation not permitted. The install lands in a copy nothing supervises.abctl service install --yes --restartfails withBoot-out failed: 1: Operation not permitted, so the service can't be restarted.Workaround
Build inside the sandbox, install outside from a host shell:
The
.new-then-mvstep matters: replacing a running executable in place fails withETXTBSY.Possible improvements
dev-installcould detect thexcode-selectshim failure and point atgmake, rather than surfacing a compiler error for a build that needs no compiler.msg="authbridge-proxy starting" version=v0.7.0-rc.1). A/v1/versionendpoint orabctl versionsubcommand would help. Note local builds reportversion=dev; only the release workflow stamps via-ldflags.