Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

[Feature]: 支持自定义 auto 模式的权限判定 prompt 与判定模型

未关闭
  • 哪里不对？
#549 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
typescript
领域
backend, cli

调研方向

Start by reading the permission service and config normalization code described in the issue, then trace the auto-mode request to POST /mavis/api/v1/permission/check and the classifier’s model selection. The request describes three changes across prompt delivery, model configuration, and working-directory rules; done means users can configure the classifier prompt and model, and control the stated boundary behavior. No test files or specific paths are named in the payload.

由索引模型根据 Issue 内容生成。

描述

enhancement needs-triage tui
Product or interface

CLI - interactive TUI

Use case and problem

在 auto（智能授权）权限模式下，我希望能够自定义权限判定所使用的 prompt，并指定用于该判定的模型。

当前这两项都无法做到，原因如下。

### 问题 1：beta.promptOverride 配置项存在，但不产生任何实际效果

MiniMax Code 提供了 beta.promptOverride 开关与 <dataDir>/internal/prompts/llm-gate-classifier.md
覆盖路径，配置确实会被读取：

// packages/local-runtime/.../permission-service.ts
function resolvePermissionPrompt(config, name) {
    if (config.beta?.promptOverride) {
        const override = readOptionalPrompt(path.join(config.dataDir, 'internal', 'prompts',
`${name}.md`));
        if (override) return override;
    }
    ...
}

但该 prompt 从不会被发送给云端判定服务。auto 模式的 LLM 判定通过 POST
/mavis/api/v1/permission/check 完成，请求体中不包含 prompt 内容，只有：

tool_name, input, platform, home_dir, workspace_root, mode,
conversation_context?, agent_id?, session_id?, daemon_prompt_version?

实际使用的 prompt 由云端服务持有。本地这份文件只是副本。

同一份代码中的官方注释也确认了这一点：

│ Prompt provider — the cloud side owns the llm-gate-classifier prompt, but this hook still serves
│ tooling/tests that import the prompt text directly.

即 resolvePrompt 仅用于工具链和测试直接读取 prompt 文本，本身不参与真实判定流程。结果是：用户按官
方方式配置了覆盖文件，却观察不到任何行为变化，且没有任何提示说明该配置无效。

### 问题 2：defaultLightModel 配置被无条件覆盖，无法指定判定模型

config.yaml 中存在 defaultLightModel 配置项，但在配置归一化时被强制覆盖：

// packages/local-runtime/.../config.ts
function toRuntimeConfig(local) {
    return {
        ...
        defaultModel: local.defaultModel,
        defaultLightModel: local.defaultModel,   // ← 无条件覆盖用户配置
        ...
    };
}

即便用户在 config.yaml 中显式写入 defaultLightModel: <某个轻量模型>，运行时仍会将其替换为
defaultModel。而分类器正是通过 H4t() 读取 defaultLightModel ?? defaultModel 来确定判定模型的。

结果是：权限分类器被迫使用与主会话相同的模型。对于一个短输入、短输出、只需返回 allow/confirm/block
 的判定任务，使用 512K 上下文的主模型既慢又贵，而且无法独立调优——用户想给分类器换个更便宜、更快的
模型都做不到。

### 问题 3：大量操作走不到 LLM 判定，prompt 无法影响结果

权限判定是多层结构，前置静态规则会先于 LLM 分类器返回结果：

┌─────────────────────────────────────────────────────────────────┬────────────────────────┐
│ 前置判定类型                                                    │ 是否进入 LLM 分类器    │
├─────────────────────────────────────────────────────────────────┼────────────────────────┤
│ workingDirectory（工作区边界）                                  │ ❌ 直接 allow/ask/deny │
├─────────────────────────────────────────────────────────────────┼────────────────────────┤
│ safetyCheck + privateRuntimeData（classifierApprovable: false） │ ❌ 硬拦截              │
├─────────────────────────────────────────────────────────────────┼────────────────────────┤
│ safetyCheck + classifierApprovable: true                        │ ✅ 进入分类器          │
└─────────────────────────────────────────────────────────────────┴────────────────────────┘

即使将来 prompt 可以自定义，用户最关心的"读取工作区外普通文件""在项目内任意写入"这两类操作，由
workingDirectory 规则直接判定，永远送不到分类器，prompt 对它们没有任何作用。用户无法通过调整
prompt 来获得期望的宽松/严格程度。
Desired behavior

希望提供以下能力，按重要性排序：

1. 可自定义 auto 判定的 prompt
    - 提供一种方式让本地 prompt 真正参与判定。可选方案：
        - 在 POST /mavis/api/v1/permission/check 请求体中携带本地 prompt 内容；或
        - 提供本地/自建判定服务的 endpoint 配置项

2. 可为分类器指定独立模型
    - 修复 defaultLightModel 被无条件覆盖的问题，使其真正生效


3. 让 prompt 能影响到 workingDirectory 类判定
    - 或至少提供一个配置项（如 permission.autoBoundaryPolicy）来控制"工作区外访问"的默认行为，避免这类操作完全绕过 LLM 判定、导致用户的 prompt 配置对其无效
Platform

Windows

Alternatives and additional context

当前的 auto 模式会有大量权限弹窗,包括阅读工作区外普通文件,执行实际为读取工作区内文件的脚本等无害内容.
而allow 功能难以范围性的覆盖这些请求.导致 auto 模式实际体验很差,被迫使用 Full access 模式.
希望能完全地使用自定义的 prompt 来让 LLM 进行判定,放行用户指定类型的权限请求.

主要语言
TypeScript
星标
2.1k
派生
271
平均合并
9 小时 55 分钟
30 天内合并 PR
52

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

MiniMax-AI/minimax-code 的其他 Issue

查看 MiniMax-AI/minimax-code 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。