Should permission defaults depend on the selected sandbox provider?

[harshlocham]

Context

Harness adapters that run coding agents inside a TanStack sandbox intentionally treat the sandbox as the security boundary. For several adapters, that shows up as production defaults that auto-approve agent tool use:

Adapter	Default when omitted	Source
ACP (acpCompatible)	permissionMode: 'bypassPermissions', permissions strategy effectively headless	packages/ai-acp/src/adapters/compatible.ts
Claude Code	permissionMode: 'bypassPermissions' → --permission-mode	packages/ai-claude-code/src/adapters/text.ts
Grok Build (ACP path)	permissionMode: 'bypassPermissions'	packages/ai-grok-build/src/adapters/text.ts
OpenCode	permissionMode: 'default'	packages/ai-opencode/src/adapters/text.ts

From tracing the code, these appear to be production defaults rather than test-only behavior.

localProcessSandbox is opt-in (it is not the library default, and the documentation recommends Docker first). Its implementation clearly documents the trust boundary:

TRUST BOUNDARY: local-process runs commands and file writes on the HOST with the privileges of the current process. It provides NO isolation, NO network policy, and exec runs through a shell. Use it only in trusted/dev contexts...

Interaction between provider and defaults

One common setup for local development is:

defineSandbox({
  provider: localProcessSandbox(),
})

chat({
  adapter: claudeCodeText(...), // or acpCompatible / grokBuildText
  middleware: [withSandbox(sandbox)],
})

If permissionMode is omitted, the ACP, Claude Code, and Grok Build adapters default to bypassPermissions.

This makes sense when the sandbox itself provides isolation, but localProcessSandbox intentionally runs directly on the host. That made me wonder whether the permission defaults should depend on the selected sandbox provider, or whether the current behavior is an intentional tradeoff for the local development workflow.

[cweekly]

Good catch! I'm not a maintainer but IMHO this should at least be documented more clearly for localProcessSandbox.