No non-interactive way to trust a workspace: headless `claude -p` silently ignores provisioned .claude/settings.json permissions in unattended runner workdirs

Summary

Headless claude -p runs in an untrusted workspace silently ignore the project's .claude/settings.json permission rules, and there is no supported non-interactive way to accept workspace trust. For unattended agent runners (supervisors that spawn claude -p in a dedicated per-session workdir), this means permission allowlists cannot be provisioned programmatically at all — the only workaround is hand-editing ~/.claude.json.

Environment

• Claude Code v2.1.216, macOS 26.4 (Darwin 25.4.0), subscription OAuth

Repro

1. Create a fresh directory (never opened interactively), e.g. an agent supervisor's per-channel workdir: ~/.agentparty/runners/<hash>/guessadmin/
2. Provision .claude/settings.json there with permissions.allow: ["Bash(party:*)", ...]
3. Run claude -p "run party --version via Bash and reply the version" with that cwd.

Observed:

Ignoring 14 permissions.allow entries from .claude/settings.json: this workspace
has not been trusted. Run Claude Code interactively here once and accept the
trust dialog, or set projects["<path>"].hasTrustDialogAccepted: true in
/Users/leo/.claude.json.

• The warning goes to the CLI's output only; the model's session sees ordinary permission denials ("This command requires approval"), so the agent inside reports "permissions not configured" and the operator (who did configure them) has no idea why — we burned three debugging rounds on exactly this (settings were in place, trust was the hidden gate).
• Hand-editing ~/.claude.json (projects["<path>"].hasTrustDialogAccepted: true) fixes it, but that's an undocumented internal file and races with concurrent sessions rewriting it (see #73364).

Expected / Ask

One (or more) of:

1. A first-class non-interactive trust command: claude trust <dir> (or claude --accept-workspace-trust -p ...) so unattended workdirs can be provisioned in scripts;
2. An env var / flag equivalent for CI & runner use;
3. At minimum: surface the "settings ignored: workspace untrusted" condition inside the session context (so the model can relay the real cause) and document the hasTrustDialogAccepted workaround.

Context

Hit while wiring an unattended on-call agent (AgentParty party serve --runner claude): wake → headless claude -p in its dedicated workdir → every tool call gated → agent can wake and read but never reply. Related but distinct: #74794 (settings silently ignored after rename), #71562/#65864 (trust flag persistence). Our report is specifically the absence of any supported non-interactive trust path.