omac start takes 75 seconds

[StephanBradler]

Duplicate check

• I have searched the existing issues

Context / Summary

omac start used to quickly open the opencode UI. It now always takes 75 seconds. No similar issue was found.

Problem / What

omac start used to quickly open the opencode UI. It now always takes 75 seconds. During startup, the warning 'omac: sandbox profile "tng-default" has an empty environment.allow_vars.' is visible. See omac doctor output below for more details.

Suggested fix / Ask

This should be fast. Either eliminate the cause or provide setup guidance on how to avoid this issue.

Non-goals

No response

Evidence / Environment

Environment:

• macOS 26.5.2
• omac was initially installed in version 0.5.0 using the installer from the TNG internal repository. omac start used to be quick in this setup. After brew upgrade to versions 0.7.0 and 0.8.0, omac start now consistently takes 75 seconds.
• opencode version 1.16.0

omac doctor output:

omac 0.8.0
OS: macos
workdir: REDACTED
[ok] keychain backend: reachable
[ok] launcher config: /Users/REDACTED/.config/omac/config.yaml
[ok] registry: 1 skill(s) registered (0 workdir, 1 global)
[ok] skill-marketplace binary=yes missing_required_secrets=0
Inner harnesses:
[ok] opencode binary=opencode found
[warn] claude-code binary=claude not on $PATH
[warn] codex binary=codex not on $PATH
[warn] copilot binary=copilot not on $PATH
[warn] pi binary=pi not on $PATH
[warn] codewhale binary=codewhale not on $PATH
[ok] built-in omac-write-a-skill (opencode): present
[ok] sandbox profile "tng-default" uses the built-in sandbox
[ok] built-in sandbox: kernel backend available
[ok] network prompt: dialog backend available
[warn] sandbox profile "tng-default" has an empty environment.allow_vars
impact: at launch omac forwards only the operational minimum (HOME, PATH,
TERM, locale, …); all other ambient env vars — including provider
tokens and secrets — are NOT passed through, and omac does not
auto-forward auth vars. This differs from the pre-#102 inherit-
everything behavior; the harness starts but will not authenticate.
remediation: add the vars the harness needs to allow_vars (see
sandboxprofile.DefaultAllowVars), or set allow_vars: [""] to forward
every ambient var (minus the danger blocklist).
[warn] sandbox profile "tng-default" Allow ~/.cache
impact: cache roots are writable/readable inside the sandbox, which can leak host-derived caches and weaken per-project isolation
remediation: remove the broad grant; let the sandbox start empty and grant specific cache subpaths only when needed
[warn] sandbox profile "tng-default" Allow ~/Library/Caches
impact: cache roots are writable/readable inside the sandbox, which can leak host-derived caches and weaken per-project isolation
remediation: remove the broad grant; let the sandbox start empty and grant specific cache subpaths only when needed
[warn] sandbox profile "tng-default" Allow ~/go
impact: tool home ~/go is writable inside the sandbox, exposing host-installed toolchains and credentials
remediation: use GOPATH inside the sandbox or grant only ~/go/bin read
[warn] sandbox profile "tng-default" Allow ~/.rustup
impact: tool home ~/.rustup is writable inside the sandbox, exposing host-installed toolchains and credentials
remediation: point RUSTUP_HOME at an isolated location inside the sandbox
[warn] sandbox profile "tng-default" Allow ~/.cargo
impact: tool home ~/.cargo is writable inside the sandbox, exposing host-installed toolchains and credentials
remediation: use an isolated CARGO_HOME and project-local .cargo/config.toml; export CARGO_REGISTRIES_TOKEN in the environment that starts omac. If the sandbox profile sets environment.allow_vars, include that exact variable so the sandboxed harness inherits it; sidecar.env_passthrough configures only the sidecar. NAME is the registry key uppercased with '-' replaced by ''
sandbox profile lint (3 finding(s), advisory):
[medium] environment.allow_vars: fails closed to the operational defaults, so the harness starts but cannot authenticate; add the vars it needs to allow_vars, or [""] to inherit every non-blocklisted var ((empty))
[medium] filesystem.read: overlaps known secret path /Users/REDACTED/.gitconfig not in baseline (git config (may embed tokens)) (~/.gitconfig)
[medium] network.allow_tcp_connect: direct outbound TCP to SSH/RDP port (22)

When a run fails, omac diagnose shows what the sandbox blocked and why.

[NoRiceToday]

I am reproducing this on the same macOS tng-default profile shape. The allow_vars warning is probably adjacent rather than the timer itself. Could you please attach two timings and the post-run diagnostic?

time omac start --no-sandbox
time omac start --verbose
omac diagnose

For each start, exit as soon as the OpenCode UI becomes usable. Please also note whether a network-access dialog or notification appears during the 75 seconds. Redact paths/tokens as needed. This separates omac pre-launch work from OpenCode egress/cache startup without weakening the eventual fix.

[NoRiceToday]

I found a concrete version boundary in the TNG installer. The profile shown by your doctor output is the pre-2026-07-20 tng-default.json (its environment block is empty). The installer fixed that in commit f97cbcd by shipping an explicit allow_vars, including SKAINET_*. Upgrading the omac Homebrew package does not update this separately installed custom profile, so 0.7+ correctly fails closed, strips the token/config environment, and the OpenCode plugin can stall during startup.

Please update the internal installer checkout, rerun ./install.sh, and accept replacement of ~/.config/omac/sandbox-profiles/tng-default.json. Then run omac doctor; the empty environment.allow_vars warning should be gone. Please report the new omac start timing. Do not use ["*"] for this profile; the current installer has the narrower intended allowlist.

[StephanBradler]

I am reproducing this on the same macOS tng-default profile shape. The allow_vars warning is probably adjacent rather than the timer itself. Could you please attach two timings and the post-run diagnostic?

time omac start --no-sandbox
time omac start --verbose
omac diagnose
For each start, exit as soon as the OpenCode UI becomes usable. Please also note whether a network-access dialog or notification appears during the 75 seconds. Redact paths/tokens as needed. This separates omac pre-launch work from OpenCode egress/cache startup without weakening the eventual fix.

Here are the results before updating the installer. There was never any network-access dialog or notification.

time omac start --no-sandbox
omac start --no-sandbox 2.92s user 0.28s system 77% cpu 4.138

time omac start --verbose
omac start --verbose 5.13s user 3.87s system 11% cpu 1:17.44

omac diagnose
omac 0.8.0 · macos · REDACTED WORKING DIRECTORY
last run exited 0 · filtered mode · 0/0 connection(s) blocked

What to look at:
• Nothing was blocked by the network policy — a failure here can be invisible to this report
Proxy-unaware tool? In filtered mode every tool must use the omac proxy (HTTP(S)_PROXY). A JVM/gradle or native client that connects directly is blocked by the kernel with no entry here — route it through the proxy (JAVA_TOOL_OPTIONS / proxy_injection).
Raw TCP (SSH, git@…, Postgres, Redis)? Non-HTTP connections do not use the proxy; they need the port in network.allow_tcp_connect. Check with omac diagnose --probe <host>:<port>.
Local socket or 127.0.0.1 service? A daemon socket (e.g. docker.sock) or loopback port is a filesystem/open_port grant, not network — check omac provenance and omac diagnose --probe 127.0.0.1:<port>.
Either way, prefer the narrowest grant; do not widen the network policy.

1 advisory note(s) about config hygiene / least privilege — run omac diagnose -v to see them.

More: omac diagnose -v (detail) · omac diagnose --probe <host[:port]> (test a host) · omac provenance (full config)

[StephanBradler]

I found a concrete version boundary in the TNG installer. The profile shown by your doctor output is the pre-2026-07-20 tng-default.json (its environment block is empty). The installer fixed that in commit f97cbcd by shipping an explicit allow_vars, including SKAINET_*. Upgrading the omac Homebrew package does not update this separately installed custom profile, so 0.7+ correctly fails closed, strips the token/config environment, and the OpenCode plugin can stall during startup.

Please update the internal installer checkout, rerun ./install.sh, and accept replacement of ~/.config/omac/sandbox-profiles/tng-default.json. Then run omac doctor; the empty environment.allow_vars warning should be gone. Please report the new omac start timing. Do not use ["*"] for this profile; the current installer has the narrower intended allowlist.

Below are the results after updating the installer. I pulled in the installer repo with main last updated on 2026-08-12. I then executed the install scripts accepting all replacements. I also needed to reregister the skill-marketplace. The allow_vars warning has disappeared, the rest seems to be the same. No network-access dialog or notification, timings practically the same.

omac doctor
omac 0.8.0
OS: macos
workdir: REDACTED
[ok] keychain backend: reachable
[ok] launcher config: /Users/REDACTED/.config/omac/config.yaml
[ok] registry: 1 skill(s) registered (0 workdir, 1 global)
[ok] skill-marketplace binary=yes missing_required_secrets=0
Inner harnesses:
[ok] opencode binary=opencode found
[warn] claude-code binary=claude not on $PATH
[warn] codex binary=codex not on $PATH
[warn] copilot binary=copilot not on $PATH
[warn] pi binary=pi not on $PATH
[warn] codewhale binary=codewhale not on $PATH
[ok] built-in omac-write-a-skill (opencode): present
[ok] sandbox profile "tng-default" uses the built-in sandbox
[ok] built-in sandbox: kernel backend available
[ok] network prompt: dialog backend available
[warn] sandbox profile "tng-default" Allow ~/.cache
impact: cache roots are writable/readable inside the sandbox, which can leak host-derived caches and weaken per-project isolation
remediation: remove the broad grant; let the sandbox start empty and grant specific cache subpaths only when needed
[warn] sandbox profile "tng-default" Allow ~/Library/Caches
impact: cache roots are writable/readable inside the sandbox, which can leak host-derived caches and weaken per-project isolation
remediation: remove the broad grant; let the sandbox start empty and grant specific cache subpaths only when needed
[warn] sandbox profile "tng-default" Allow ~/go
impact: tool home ~/go is writable inside the sandbox, exposing host-installed toolchains and credentials
remediation: use GOPATH inside the sandbox or grant only ~/go/bin read
[warn] sandbox profile "tng-default" Allow ~/.rustup
impact: tool home ~/.rustup is writable inside the sandbox, exposing host-installed toolchains and credentials
remediation: point RUSTUP_HOME at an isolated location inside the sandbox
[warn] sandbox profile "tng-default" Allow ~/.cargo
impact: tool home /.cargo is writable inside the sandbox, exposing host-installed toolchains and credentials
remediation: use an isolated CARGO_HOME and project-local .cargo/config.toml; export CARGO_REGISTRIES_TOKEN in the environment that starts omac. If the sandbox profile sets environment.allow_vars, include that exact variable so the sandboxed harness inherits it; sidecar.env_passthrough configures only the sidecar. NAME is the registry key uppercased with '-' replaced by ''
sandbox profile lint (2 finding(s), advisory):
[medium] filesystem.read: overlaps known secret path /Users/REDACTED/.gitconfig not in baseline (git config (may embed tokens)) (/.gitconfig)
[medium] network.allow_tcp_connect: direct outbound TCP to SSH/RDP port (22)

When a run fails, omac diagnose shows what the sandbox blocked and why.

time omac start --no-sandbox
omac start --no-sandbox 2.88s user 0.29s system 81% cpu 3.908 total

time omac start --verbose
omac start --verbose 4.99s user 3.59s system 11% cpu 1:15.49 totall

omac diagnose
omac 0.8.0 · macos · REDACTED WORKING DIRECTORY
last run exited 0 · filtered mode · 0/1 connection(s) blocked

What to look at:
• Nothing was blocked by the network policy — a failure here can be invisible to this report
Proxy-unaware tool? In filtered mode every tool must use the omac proxy (HTTP(S)_PROXY). A JVM/gradle or native client that connects directly is blocked by the kernel with no entry here — route it through the proxy (JAVA_TOOL_OPTIONS / proxy_injection).
Raw TCP (SSH, git@…, Postgres, Redis)? Non-HTTP connections do not use the proxy; they need the port in network.allow_tcp_connect. Check with omac diagnose --probe <host>:<port>.
Local socket or 127.0.0.1 service? A daemon socket (e.g. docker.sock) or loopback port is a filesystem/open_port grant, not network — check omac provenance and omac diagnose --probe 127.0.0.1:<port>.
Either way, prefer the narrowest grant; do not widen the network policy.

1 advisory note(s) about config hygiene / least privilege — run omac diagnose -v to see them.

More: omac diagnose -v (detail) · omac diagnose --probe <host[:port]> (test a host) · omac provenance (full config)

[NoRiceToday]

Thanks, this rules out the stale allow_vars profile as the main cause. The roughly two-second improvement matches omac's warning delay, while about 72 seconds of sandbox-only overhead remain.

I have not been able to reproduce the 75-second delay locally, so could you help with one more A/B test?

Please create a temporary copy of the updated tng-default policy named tng-open-net, changing only network.mode from "filtered" to "open". Keep its filesystem and environment configuration unchanged and add a corresponding temporary launcher profile. Then compare:

time omac start --sandbox tng-default
time omac start --sandbox tng-open-net

Exit each run as soon as the OpenCode UI becomes usable.

• If tng-open-net starts quickly, the delay is likely in the filtered network/proxy path.
• If it still takes about 75 seconds, we can rule that path out and investigate environment versus filesystem restrictions next.

network.mode: open allows unrestricted egress during that run, so please use it only for this diagnostic and remove the temporary profile afterwards.

Could you also attach the complete verbose output and detailed diagnosis? The previous comment contained the timing but not the lifecycle/sandbox log:

time omac start --verbose 2> /tmp/omac-start-verbose.log
omac diagnose -v

Please attach the redacted contents of /tmp/omac-start-verbose.log together with the omac diagnose -v output.

[StephanBradler]

Here is the output of the requested tests:

time omac start --sandbox tng-default
omac start --sandbox tng-default 5.23s user 3.55s system 10% cpu 1:24.01 total

time omac start --sandbox tng-open-net
omac start --sandbox tng-open-net 5.02s user 3.16s system 10% cpu 1:21.40 total

time omac start --verbose 2> /tmp/omac-start-verbose.log
[verbose] loaded launcher config: REDACTED
[verbose] runtime dir: REDACTED
[verbose] sandbox TMPDIR: REDACTED
[verbose] cache mode=persistent path= REDACTED
[verbose] facade listening on REDACTED
[verbose] control plane: REDACTED
[verbose] sandbox argv: REDACTED
2026-08-26 15:06:57 INFO fs skipping nonexistent path /usr/local/lib
2026-08-26 15:06:57 INFO fs skipping nonexistent path /private/var/db/dyld
2026-08-26 15:06:57 INFO fs skipping nonexistent path /usr/local/Cellar
2026-08-26 15:06:57 INFO fs skipping nonexistent path /usr/local/opt
2026-08-26 15:06:57 INFO fs skipping nonexistent path /Users/REDACTED/.opencode/bin
2026-08-26 15:06:57 INFO fs skipping nonexistent path /Users/REDACTED/.gitignore_global
2026-08-26 15:06:57 INFO fs skipping nonexistent path /Users/REDACTED/.claude.json
2026-08-26 15:06:57 INFO fs skipping nonexistent path /Users/REDACTED/.claude
2026-08-26 15:06:57 INFO fs skipping nonexistent path /Users/REDACTED/go
2026-08-26 15:06:57 INFO fs skipping nonexistent path /Users/REDACTED/.opencode
2026-08-26 15:07:03 INFO fs filesystem.deny scan of /Users/REDACTED/Library/Caches hit the 200000-entry limit; some matches may be unmasked

To resume this session: omac continue -s REDACTED

omac diagnose -v
omac 0.8.0 · macos · REDACTED WORKING DIRECTORY
last run exited 0 · filtered mode · 0/0 connection(s) blocked

What to look at:
• Nothing was blocked by the network policy — a failure here can be invisible to this report
Proxy-unaware tool? In filtered mode every tool must use the omac proxy (HTTP(S)_PROXY). A JVM/gradle or native client that connects directly is blocked by the kernel with no entry here — route it through the proxy (JAVA_TOOL_OPTIONS / proxy_injection).
Raw TCP (SSH, git@…, Postgres, Redis)? Non-HTTP connections do not use the proxy; they need the port in network.allow_tcp_connect. Check with omac diagnose --probe <host>:<port>.
Local socket or 127.0.0.1 service? A daemon socket (e.g. docker.sock) or loopback port is a filesystem/open_port grant, not network — check omac provenance and omac diagnose --probe 127.0.0.1:<port>.
Either way, prefer the narrowest grant; do not widen the network policy.

Advisories (least-privilege / context):
• Environment variables are allow-listed
Ambient variables not in environment.allow_vars are stripped inside the sandbox. If a tool needs one, add it there.

Effective network policy (profile "default", ):
mode=filtered prompt=on
allow_domain: (none)
(full effective config across all subsystems: omac provenance)

audit trail: REDACTED
raw sandbox log (TTY sessions): REDACTED
More: omac diagnose -v (detail) · omac diagnose --probe <host[:port]> (test a host) · omac provenance (full config)

[NoRiceToday]

The new evidence points to OpenCode plugin resolution, not the network filter itself.

omac 0.5.1+ redirects XDG_CACHE_HOME into an omac-managed cache. OpenCode therefore resolves its configured @tngtech/opencode-skainet@latest plugin inside that cache. The @tngtech scope-to-registry mapping lives in ~/.npmrc, which the sandbox correctly masks because the same file may contain an auth token. Without the mapping, npm/Bun queries the public npm registry, gets a 404, and OpenCode waits/retries during plugin initialization.

This explains every A/B result:

• --no-sandbox is fast because OpenCode sees the host npm configuration and warm host cache.
• network.mode: open is still slow because egress was not the problem; the request targets the wrong registry.
• No dialog or diagnose denial appears because the public-registry request is technically allowed.
• Updating allow_vars does not restore a masked filesystem config.

The same mechanism was reproduced end-to-end in #155: with ~/.npmrc masked, OpenCode contacted registry.npmjs.org and loaded zero skainet models; with only the registry mapping available, it contacted the internal registry and installed the plugin.

The clean fix is already implemented in #259: filesystem.registry_config: ["npm"] projects only credential-free registry mappings into the sandbox and keeps the real ~/.npmrc (and any token) masked. Its acceptance test installs the actual TNG plugin from a cold cache, and all PR checks are green. After #259 is merged/released, the TNG installer profile should enable that knob and the affected user should run omac cache clear once before retiming. Do not use override_deny: ["~/.npmrc"]; that exposes the entire token-bearing file.

The ~/Library/Caches 200,000-entry scan is a separate, smaller cost: the timestamp shows about six seconds, not the remaining ~70 seconds. The TNG profile should still remove broad cache/toolchain grants in favor of omac's isolated cache redirects, both for startup time and least privilege.

Refs #155, #241, #259