[Bug] 关于 SkillHub 发布与安装流程的几个疑问

[guoguoguilai]

Summary

你好，我们团队最近在使用 SkillHub 过程中遇到了一些问题，想确认一下是否属于已知行为，还是 bug。

1. npx clawhub install 对非 global namespace 的 skill 必然失败

CLI 安装时会调用 /resolve?version=latest，但官方发布流程（POST /api/v1/skills/{ns}/publish）并不会自动给版本打 latest tag，导致所有非 global namespace 的 skill 安装必然报 "Skill not found"。请问打 latest tag 是否有标准流程？

2. 版本号被忽略，自动赋时间戳

通过 CLI（npx clawhub publish）发布时，无论 package.json 的 version 字段还是 --version 参数，服务端都会忽略，强制赋 yyyyMMdd.HHmmss 格式的时间戳版本。版本号只有写在 SKILL.md frontmatter 里才生效。这是预期行为吗？建议在文档中说明。

3. Secret Scanner 对 Python 关键字参数误报

发布包含 Python 代码时，Scanner 会把 token=variable_name 这类普通关键字参数误判为密钥泄露并拦截发布。绕过方式是在请求中加 ?confirmWarnings=true，但此参数未在任何文档中提及，我们是通过反编译 jar 才找到的。能否在文档中说明？

4. Tag 写入 API 对所有用户返回 403

PUT /api/v1/skills/{ns}/{slug}/versions/{version}/tags/{tag} 端点存在，但无论使用什么 token 均返回 403。请问这个接口是否需要特殊角色？如果普通用户无法操作，是否有替代方案？

5. /api/v1/whoami 返回 schema 模板而非真实数据

调用 /api/v1/whoami 时，响应体是 schema 占位符（如 displayName: string），而非实际用户信息。怀疑是 mock 未关闭或 API gateway 配置问题。

6. CLI 与服务端文件扩展名白名单不同步

CLI 内部有独立的 listTextFiles 过滤逻辑，服务端也有自己的扩展名白名单，两者不一致。常见运维文件（如 Dockerfile、deploy.env）无法通过 CLI 发布，必须手写 curl 请求。

以上问题我们已通过自写脚本绕过，但希望确认是否属于已知问题或规划中的改进项。感谢！

Steps To Reproduce

同上

Expected Behavior

同上

Environment

No response

API Contract Impact

No response

Logs Or Screenshots

No response

[github-actions]

Issue Triage

• Route: triage/core
• Priority: priority/p0 (4.5/5)
• Effort: effort/m (3/5)
• Confidence: 2/5
• Risk: high
• Analysis Mode: rules-only

Why

• Touches core SkillHub workflows (publish, namespace, token).
• Blocks a documented user workflow (clawhub publish, clawhub install).
• Text suggests a bounded change (text).
• Issue is missing key context (steps to reproduce, expected behavior).

High-Risk Signals

• Mentions sensitive areas (token, secret, schema).

Maintainer Brief

Summary: 你好，我们团队最近在使用 SkillHub 过程中遇到了一些问题，想确认一下是否属于已知行为，还是 bug。 1. npx clawhub install 对非 global namespace 的 skill 必然失败 CLI 安装时会调用 /resolve?version=latest，但官方发布流程（POST /api/v1/skills/{ns}/publish）并不会自动给版本打 latest tag，导致所有非 global namespace 的 skill 安装必然报 "Skill not found"。请问打 latest tag 是否有标准流程？ 2. 版本号被忽略，自动赋时间戳 通过 CLI（npx clawhub publish）发布时，无论 package.json 的 version 字段还是 --version 参数，服务端都会忽略，强制赋 yyyyMMdd.HHmmss 格式的时间戳版本。版本号只有写在 SKILL.md frontmatter 里才生效。这是预期行为吗？建议在文档中说明。 3. Secret Scanner 对 Python 关键字参数误报 发布包含 Python 代码时，Scanner 会把 token=variable_name 这类普通关键字参数误判为密钥泄露并拦截发布。绕过方式是在请求中加 ?confirmWarnings=true，但此参数未在任何文档中提及，我们是通过反编译 jar 才找到的。能否在文档中说明？ 4. Tag 写入 API 对所有用户返回 403 PUT /api/v1/skills/{ns}/{slug}/versions/{version}/tags/{tag} 端点存在，但无论使用什么 token 均返回 403。请问这个接口是否需要特殊角色？如果普通用户无法操作，是否有替代方案？ 5. /api/v1/whoami 返回 schema 模板而非真实数据 调用 /api/v1/whoami 时，响应体是 schema 占位符（如 displayName: string），而非实际用户信息。怀疑是 mock 未关闭或 API gateway 配置问题。 6. CLI 与服务端文件扩展名白名单不同步 CLI 内部有独立的 listTextFiles 过滤逻辑，服务端也有自己的扩展名白名单，两者不一致。常见运维文件（如 Dockerfile、deploy.env）无法通过 CLI 发布，必须手写 curl 请求。 以上问题我们已通过自写脚本绕过，但希望确认是否属于已知问题或规划中的改进项。感谢！
Why core:

• Blocks an OpenClaw/ClawHub core workflow, so maintainer judgment is required even if the code change looks bounded.
• Touches a higher-risk area where automated fixes should not be trusted without maintainer review.
• The issue is important, but a maintainer still needs to tighten scope before implementation.
• Mentions sensitive areas (token, secret, schema).
  Reproduction or operator path:
• 同上
  Suspected areas:
• CLI publish command option parsing and namespace-aware publish flow
• Skill installation flow and registry/lockfile integration
• Authentication, session, and identity integration
• Security scanner pipeline and audit/reporting behavior
  Risks to watch:
• Mentions sensitive areas (token, secret, schema).
• Namespace-scoped behavior can regress default publish/install flows if fallback routing is not preserved.
• This issue affects a documented primary workflow, so regressions would be visible to end users quickly.
  Validation checklist:
• Replay the exact reproduction steps from the issue and confirm the reported failure disappears.
• Confirm the final behavior matches the issue's expected outcome: 同上
• Verify both namespace-scoped behavior and the default non-namespace flow.
• Run the smallest relevant regression test around the affected OpenClaw/ClawHub user journey.

Missing Info

• Please add steps to reproduce.
• Please add expected behavior.

Next Action

• Hand the issue to a core maintainer and use a local programming agent for reproduction, scoping, and validation.

---

问题分流结果

• 路由: triage/core
• 优先级: priority/p0 (4.5/5)
• 修复投入: effort/m (3/5)
• 信息完整度: 2/5
• 风险: 高
• 分析模式: rules-only

原因

• 涉及 SkillHub 核心流程（publish, namespace, token）
• 阻塞已定义的用户主流程（clawhub publish, clawhub install）
• 文本显示改动范围较可控（text）
• 缺少关键上下文（steps to reproduce, expected behavior）

高风险信号

• 提到敏感区域（token, secret, schema）

维护者交接摘要

概要: 你好，我们团队最近在使用 SkillHub 过程中遇到了一些问题，想确认一下是否属于已知行为，还是 bug。 1. npx clawhub install 对非 global namespace 的 skill 必然失败 CLI 安装时会调用 /resolve?version=latest，但官方发布流程（POST /api/v1/skills/{ns}/publish）并不会自动给版本打 latest tag，导致所有非 global namespace 的 skill 安装必然报 "Skill not found"。请问打 latest tag 是否有标准流程？ 2. 版本号被忽略，自动赋时间戳 通过 CLI（npx clawhub publish）发布时，无论 package.json 的 version 字段还是 --version 参数，服务端都会忽略，强制赋 yyyyMMdd.HHmmss 格式的时间戳版本。版本号只有写在 SKILL.md frontmatter 里才生效。这是预期行为吗？建议在文档中说明。 3. Secret Scanner 对 Python 关键字参数误报 发布包含 Python 代码时，Scanner 会把 token=variable_name 这类普通关键字参数误判为密钥泄露并拦截发布。绕过方式是在请求中加 ?confirmWarnings=true，但此参数未在任何文档中提及，我们是通过反编译 jar 才找到的。能否在文档中说明？ 4. Tag 写入 API 对所有用户返回 403 PUT /api/v1/skills/{ns}/{slug}/versions/{version}/tags/{tag} 端点存在，但无论使用什么 token 均返回 403。请问这个接口是否需要特殊角色？如果普通用户无法操作，是否有替代方案？ 5. /api/v1/whoami 返回 schema 模板而非真实数据 调用 /api/v1/whoami 时，响应体是 schema 占位符（如 displayName: string），而非实际用户信息。怀疑是 mock 未关闭或 API gateway 配置问题。 6. CLI 与服务端文件扩展名白名单不同步 CLI 内部有独立的 listTextFiles 过滤逻辑，服务端也有自己的扩展名白名单，两者不一致。常见运维文件（如 Dockerfile、deploy.env）无法通过 CLI 发布，必须手写 curl 请求。 以上问题我们已通过自写脚本绕过，但希望确认是否属于已知问题或规划中的改进项。感谢！
为何进入 core:

• 阻塞 OpenClaw/ClawHub 核心工作流，因此即便改动范围看起来可控，也需要 maintainer judgment
• 触及高风险区域，未经 maintainer 审查不应直接信任自动修复
• 问题本身重要，但仍需要 maintainer 先收敛范围再实施
• 提到敏感区域（token, secret, schema）
  复现路径或操作路径:
• 同上
  怀疑影响区域:
• CLI 发布命令参数解析与 namespace 感知发布流程
• 技能安装流程与 registry/lockfile 集成
• 认证、会话与身份集成
• 安全扫描流程与审计/报告行为
  重点风险:
• 提到敏感区域（token, secret, schema）
• namespace 范围行为如果没有保留 fallback routing，可能回归默认 publish/install 流程
• 该问题影响已定义主流程，回归会很快被终端用户感知
  验证清单:
• 按 issue 中的复现步骤逐条回放，确认报告的问题已消失
• 确认最终行为符合 issue 期望
• 同时验证 namespace 范围行为与默认非 namespace 流程
• 围绕受影响的 OpenClaw/ClawHub 用户路径执行最小必要回归测试

缺失信息

• 请补充 steps to reproduce.
• 请补充 expected behavior.

下一步

• 交给 core maintainer，并结合本地编程Agent协助完成复现、收敛范围与验证闭环