`-p` silently forces permission mode "auto", auto-approving all tool calls (undocumented)

Environment: kimi-code 0.29.0, macOS (arm64), default config (default_permission_mode unset → documented default manual).

Summary: Non-interactive prompt mode (kimi -p "...") silently switches the session to auto permission mode, auto-approving every tool call — including MCP tools that mutate external systems. Neither -p's help text nor the permission docs mention this; -y/--yolo and --auto read as the explicit opt-ins, so users reasonably expect -p to inherit the manual default.

Repro: register any HTTP MCP server with a mutating tool (I used Basic Memory's write_note), then run kimi -p "create a test note ...". The write executes with no approval. The session wire log confirms the mode switch at session start:

{"type":"permission.set_mode","mode":"auto"}

followed by an injected system reminder: "Auto permission mode is active. Tool approvals will be handled automatically while this mode remains enabled."

Expected: either -p respects default_permission_mode (rejecting approval-required calls when non-interactive), or the auto-approval behavior is prominently documented in -p help and the permissions docs.

Why it matters: users running kimi -p over untrusted input (CI, cron, piped content) get silent full-trust tool execution they never opted into. [[permission.rules]] deny rules do still fire in this mode (verified), but ask-tier gating vanishes. This is at minimum a security-relevant documentation gap.

Related: #2100 (same permission-layer investigation)

Start with the kimi -p entry point, its help text, and the permission documentation; reproduce the behavior with a mutating HTTP MCP tool and inspect the session wire log for permission.set_mode. Review related issue #2100 before deciding whether the completed change should make non-interactive mode respect the configured default or clearly document its auto-approval behavior.