navikt/cplt

Landlock's access set covers opening, reading, writing, executing and directory mutation. It has no stat right: stat(2) and faccessat(2) are not mediated at all. So on Linux, access(R_OK) returns success for a path that open(2) will then refuse with EACCES. Any program written as check, then use is told one thing by the kernel and the opposite by the next syscall. Reported by @nortesoftware in #180, who found it while correcting their own bug report — the yarn 1 failure there is one instance of this, not the subject. Why it matters beyond one tool It is a real macOS/Linux divergence, and #386 had not accounted for it. Seatbelt denies the metadata call as well, so a check-then-use loader takes the "absent" branch on macOS and the "present, then fails" branch on Linux. Same configuration, different program behaviour, and not because of anything cplt chose — which is exactly the category #386 exists to enumerate. It also explains a symptom that otherwise looks tool-specific: npm, pnpm

Found while fixing the Fable review findings in #321, and left out of that PR because it is a default grant rather than a cross-backend divergence. generate_policy grants ~/.copilot read + write + execute on Linux whenever the agent needs it (src/sandbox_landlock.rs:764-772). The comment gives the reason: Execute needed for dlopen() of native .node addons (keytar, pty, computer). That reason does not hold on Landlock, and #243 established why earlier the same day. Landlock checks EXECUTE on execve() only — file_open with FMODE_EXEC — and has no mmap(PROT_EXEC) hook at all. Loading a shared object needs READ_FILE, which the rule already grants. So the execute bit buys nothing for dlopen. What it does produce is a writable and executable tree, granted by default, in the directory the agent writes its own config to. That is the binary-drop pair validate_exec_grants refuses when a user asks for it explicitly, and that #238 and #243 spent the day removing everywhere else. Here it arri

Suspected bug from code reading, not an observed failure. I have not run a Kotlin/Native build under cplt, and I could not from this machine. Filing it so the analysis is not lost, and because settling it is cheap for anyone who has a K/N project. The claim ~/.konan is a HOME_TOOL_DIRS entry with process_exec: false, map_exec: true, write: true (sandbox_policy.rs:1208). Because the tree is writable and not process_exec, macOS emits a compensating (deny process-exec (subpath "~/.konan")) — the deny is asserted directly by profile_konan_has_map_exec_only: .konan should NOT have process-exec .konan should have explicit process-exec DENY (writable dir) .konan should have file-map-executable for Kotlin Native libs Kotlin/Native downloads a prebuilt LLVM/clang toolchain into ~/.konan/dependencies/ and a native build links through it. That link step is an execve of a file under ~/.konan, not a dlopen. file-map-executable — which is what the entry grants — does not cover execve; process

Agent::keychain_substitute_env_vars() returns &[] for Copilot, with a comment at src/agent.rs saying why: Copilot gets no substitute until somebody probes it. It is the default, priority-1 agent, GITHUB_TOKEN is the most commonly exported token on a developer machine, and whether Copilot CLI prefers the env var over the Keychain is exactly the precedence question this trade declines to assume. Re-enable this with ["COPILOT_GITHUB_TOKEN", "GH_TOKEN", "GITHUB_TOKEN"] once a run under a grant-dropped profile has been confirmed to authenticate. That confirmation has never been done. It is the only thing standing between the mechanism #257 landed and dropping the whole-Keychain grant for the default agent, which is the single largest posture win available in this area: the grant is read+write on ~/Library/Keychains, so it exposes every credential the user owns, not the GitHub one. Why it needs a real run rather than an argument #173 asserted that an injected token suffices and was closed

Summary discover_electron_app documents support for editors it can never actually match. Its docstring says: Also works for VS Code Insiders, Cursor, Windsurf, and other Electron editors. But the function returns early unless the binary is a shell script whose contents include copilotCLIShim.js: if !content.starts_with("#!") { return None; } if !content.contains("copilotCLIShim.js") { return None; } So it only ever fires for a Copilot CLI shim that borrows an editor's Electron runtime. It cannot fire for launching Cursor, Windsurf, or VS Code themselves, or for any other Electron-based agent that is not the Copilot shim. Why it matters The grant this produces — file-read* plus file-map-executable on an .app/Contents — is exactly what any Electron process needs for dyld to load the Electron Framework. Without it the process takes an immediate SIGABRT. That makes this function the natural building block for #258, but it is currently welded to one caller. Measured: third-par