Describe the feature or problem you'd like to solve
GitHub Copilot CLI's macOS local sandbox does not expose a way to allow a specific third-party Mach/XPC service.
A concrete example is 1Password CLI desktop app integration, which needs to look up:
2BUA8C4S2C.com.1password.browser-helper
This blocks credential-helper chains such as:
aws
-> credential_process
-> credential helper script
-> op CLI
-> NSXPCConnection / mach-lookup
-> 2BUA8C4S2C.com.1password.browser-helper
Granting access to the executables, configuration files, 1Password Unix socket, and network destinations is not enough. Seatbelt treats Mach service discovery as the separate mach-lookup capability.
Copilot CLI 1.0.86-0 exposes only keychainAccess under sandbox.userPolicy.seatbelt. Its installed API schema defines SandboxConfigUserPolicySeatbelt with only that property and additionalProperties: false. Adding extraMachLookups to user settings produces no validation error, but the setting is inert and does not change the effective Seatbelt policy.
keychainAccess is not a substitute for an XPC allowlist. It grants a broad set of Apple Keychain and trust services plus Keychain-related filesystem paths, but it does not allow the third-party 1Password browser-helper service. The remaining workaround is to bypass the sandbox for the command, removing substantially more isolation than this workflow requires.
The underlying Microsoft MXC Seatbelt backend already supports exact-name lookups through seatbelt.extraMachLookups. The missing layer appears to be Copilot CLI's settings/API pass-through to MXC rather than a macOS Seatbelt limitation.
Proposed solution
Expose MXC's exact-name Mach lookup list in Copilot's sandbox policy:
{
"sandbox": {
"userPolicy": {
"seatbelt": {
"extraMachLookups": [
"2BUA8C4S2C.com.1password.browser-helper"
]
}
}
}
}
The minimum implementation could pass each configured value to MXC's existing seatbelt.extraMachLookups field, producing a narrow rule equivalent to:
(allow mach-lookup
(global-name "2BUA8C4S2C.com.1password.browser-helper"))
Suggested security properties and acceptance criteria:
- Accept exact Mach service names only. Reject empty values, glob patterns, regular expressions, and prefix wildcards.
- Keep the setting independent from
keychainAccess.
- Include the effective lookup list in
/sandbox policy so the grant is visible and auditable.
- Confirm that the configured 1Password helper lookup succeeds while an unrelated Mach service remains denied.
- Do not implicitly grant
mach-register, all Mach lookups, GUI access, Apple Events, or a raw Seatbelt profile override.
Example prompts or workflows
With an AWS profile whose credential_process refreshes through 1Password desktop integration:
List the caller identity for this AWS profile.
The AWS CLI invokes its credential helper, which invokes op. The helper should reach the configured 1Password XPC service without the entire command running outside the sandbox.
Additional context
Environment:
- GitHub Copilot CLI
1.0.86-0
- macOS
26.6.2 (25G83)
- Apple silicon (
arm64)
- 1Password CLI
2.38.1
To isolate the blocked capability from credentials and the rest of the AWS helper chain, I compiled a small probe whose only relevant operation is:
bootstrap_look_up(
bootstrap_port,
"2BUA8C4S2C.com.1password.browser-helper",
&port
);
The probe does not call op, retrieve a credential, access a Unix socket, or make a network request. I ran the identical binary in each context:
| Context |
Copilot Seatbelt setting |
Result |
| Host, outside Copilot's sandbox |
Not applicable |
Exit 0: mach-lookup allowed |
| Copilot Bash tool in the local sandbox |
keychainAccess: true |
Exit 1: mach-lookup failed: 1100 (Permission denied) |
| Copilot Bash tool using an isolated settings directory |
Proposed extraMachLookups value |
Exit 1: mach-lookup failed: 1100 (Permission denied) |
The host result confirms that the service is registered. The sandbox result isolates the failure to mach-lookup; unrelated socket, filesystem, network, and Keychain grants cannot satisfy that operation. The isolated-settings result confirms that extraMachLookups is silently ineffective in Copilot 1.0.86-0.
This diagnostic does not reproduce the full credential chain. A sandboxed AWS command can succeed while credentials are cached; the user-visible failure occurs when the helper must refresh through 1Password desktop integration.
Relevant references:
Describe the feature or problem you'd like to solve
GitHub Copilot CLI's macOS local sandbox does not expose a way to allow a specific third-party Mach/XPC service.
A concrete example is 1Password CLI desktop app integration, which needs to look up:
This blocks credential-helper chains such as:
Granting access to the executables, configuration files, 1Password Unix socket, and network destinations is not enough. Seatbelt treats Mach service discovery as the separate
mach-lookupcapability.Copilot CLI
1.0.86-0exposes onlykeychainAccessundersandbox.userPolicy.seatbelt. Its installed API schema definesSandboxConfigUserPolicySeatbeltwith only that property andadditionalProperties: false. AddingextraMachLookupsto user settings produces no validation error, but the setting is inert and does not change the effective Seatbelt policy.keychainAccessis not a substitute for an XPC allowlist. It grants a broad set of Apple Keychain and trust services plus Keychain-related filesystem paths, but it does not allow the third-party 1Password browser-helper service. The remaining workaround is to bypass the sandbox for the command, removing substantially more isolation than this workflow requires.The underlying Microsoft MXC Seatbelt backend already supports exact-name lookups through
seatbelt.extraMachLookups. The missing layer appears to be Copilot CLI's settings/API pass-through to MXC rather than a macOS Seatbelt limitation.Proposed solution
Expose MXC's exact-name Mach lookup list in Copilot's sandbox policy:
{ "sandbox": { "userPolicy": { "seatbelt": { "extraMachLookups": [ "2BUA8C4S2C.com.1password.browser-helper" ] } } } }The minimum implementation could pass each configured value to MXC's existing
seatbelt.extraMachLookupsfield, producing a narrow rule equivalent to:(allow mach-lookup (global-name "2BUA8C4S2C.com.1password.browser-helper"))Suggested security properties and acceptance criteria:
keychainAccess./sandbox policyso the grant is visible and auditable.mach-register, all Mach lookups, GUI access, Apple Events, or a raw Seatbelt profile override.Example prompts or workflows
With an AWS profile whose
credential_processrefreshes through 1Password desktop integration:The AWS CLI invokes its credential helper, which invokes
op. The helper should reach the configured 1Password XPC service without the entire command running outside the sandbox.Additional context
Environment:
1.0.86-026.6.2(25G83)arm64)2.38.1To isolate the blocked capability from credentials and the rest of the AWS helper chain, I compiled a small probe whose only relevant operation is:
The probe does not call
op, retrieve a credential, access a Unix socket, or make a network request. I ran the identical binary in each context:0:mach-lookup allowedkeychainAccess: true1:mach-lookup failed: 1100 (Permission denied)extraMachLookupsvalue1:mach-lookup failed: 1100 (Permission denied)The host result confirms that the service is registered. The sandbox result isolates the failure to
mach-lookup; unrelated socket, filesystem, network, and Keychain grants cannot satisfy that operation. The isolated-settings result confirms thatextraMachLookupsis silently ineffective in Copilot1.0.86-0.This diagnostic does not reproduce the full credential chain. A sandboxed AWS command can succeed while credentials are cached; the user-visible failure occurs when the helper must refresh through 1Password desktop integration.
Relevant references:
extraMachLookupsas exact service names and describes the broaderkeychainAccessandguiAccessgrants.allowMachLookup.