Repository navigation
Unauthorized Config Mutation #71
Description
SkillClaw Bug Report
Date: 2026-08-08
Version: 0.4.0
Install source: /ZFS3WAY24B/hermes/skills-upstream/SkillClaw
Install path: /ZFS3WAY24B/hermes/skillclaw-venv
Config: /home/aio/.skillclaw/config.yaml
Summary
SkillClaw exhibits two significant issues during initial setup and migration:
- Unwanted auto-editing of an unrelated/incorrect Hermes profile config
- Failure to import existing user config into its own config during setup/migration
Issue 1: Unauthorized Config Mutation
Expected
SkillClaw should either:
- Only modify the config file explicitly selected during setup, or
- Prompt before editing any config file, or
- Clearly document that it will auto-edit Hermes config on startup
Actual
On startup, SkillClaw's ClawAdapter automatically edits /home/aio/.hermes/config.yaml (the aio profile) even though:
- The user never explicitly selected this config for modification
- The user's primary/active Hermes profile is the ZFS profile at
/ZFS3WAY24B/hermes/config.yaml - The aio profile was not the intended migration target
Impact
- Non-idempotent mutation: every restart of SkillClaw rewrites the aio config
- Breaks user expectations about config ownership
- Modifies a config that SkillClaw itself identified as the "wrong" profile
- Requires manual restore from backup after every SkillClaw restart if the user wants to keep the original config
Evidence
- Backup created before first run:
/home/aio/.skillclaw/backups/hermes/config.20260808T103057Z.yaml - Diff shows SkillClaw changed:
model.provider:nous→custommodel.base_url:https://inference-api.nousresearch.com/v1→http://127.0.0.1:30000/v1model.api_key: actual key →skillclaw- List indentation across multiple sections
- After restoring backup and restarting SkillClaw, it re-edited the same file again
- Log output:
[ClawAdapter] Hermes config updated: /home/aio/.hermes/config.yaml
Issue 2: Config Import/Migration Failure
Expected
When setting up SkillClaw alongside an existing Hermes installation, the user's current LLM/provider settings should be preserved in SkillClaw's own config (/home/aio/.skillclaw/config.yaml).
Actual
SkillClaw's setup wizard and auto-config did not import the user's existing Hermes config settings into its own config. The generated /home/aio/.skillclaw/config.yaml contained:
llm.provider: customllm.model_id: ""llm.api_base: ""llm.api_key: ""
Meanwhile, the actual Hermes config had:
model.provider: nousmodel.base_url: https://inference-api.nousresearch.com/v1model.default: stepfun/step-3.7-flash:free
These were never transferred into SkillClaw's config. SkillClaw therefore started with empty upstream settings and would not have been able to forward requests correctly without manual intervention.
Impact
- User must manually reconstruct provider config in two places
- Defeats the purpose of an "auto-migration" or setup wizard
- Risk of misconfigured/misrouted LLM calls if not caught
Reproduction
- Install SkillClaw:
pip install -e /path/to/SkillClaw - Create minimal config:
/home/aio/.skillclaw/config.yamlwithclaw_type: hermes - Start SkillClaw:
skillclaw start - Observe:
/home/aio/.hermes/config.yamlis modified without explicit consent - Observe:
/home/aio/.skillclaw/config.yamldoes not contain the original Hermes provider settings
Workaround Applied
- Backed up current Hermes configs and SkillClaw config to
/home/aio/.skillclaw/backups/hermes/pre-migration-20260808T204626 - Restored
/home/aio/.hermes/config.yamlfrom SkillClaw's own backup - Manually wrote correct Nous provider settings into
/home/aio/.skillclaw/config.yaml - Manually updated the ZFS Hermes config to use the SkillClaw proxy
Desired Behavior
- SkillClaw should only edit config files explicitly selected by the user during
skillclaw setup - SkillClaw should import existing Hermes config into its own config during setup
- SkillClaw should document its auto-config behavior clearly in the setup wizard
- SkillClaw should respect multi-profile setups and not assume
~/.hermes/config.yamlis the only/primary config
Bug report written to /ZFS3WAY24B/wiki/skillclaw-bug-report-20260808.md.
Summary of what happened:
- SkillClaw auto-edited /home/aio/.hermes/config.yaml on startup without explicit consent
- It replaced your Nous provider config with its proxy settings
- On every restart it re-applies the same edit
- Its own config at /home/aio/.skillclaw/config.yaml was generated with empty LLM settings — it never imported your actual provider config
Current state after migration:
- Home config: restored to original Nous provider
- ZFS config: routed through SkillClaw proxy
- SkillClaw config: manually updated with your Nous provider details
- Both Hermes profiles now use SkillClaw proxy consistently
- Pre-migration backup at /home/aio/.skillclaw/backups/hermes/pre-migration-20260808T204626
The remaining issue is that SkillClaw will keep re-editing the aio config on restart. Want me to patch that behavior next, or leave it for now?
Activity
Upper9527 commentedon Aug 17, 2026
Confirmed. The current implementation selects
~/.hermes/config.yamlunconditionally, so the wrong-profile mutation is real.PR #72 addresses explicit target selection through
HERMES_CONFIG/HERMES_HOME; I reviewed it and asked the author to fix the Ruff formatting gate before merge. I am keeping this issue open because #72 only fixes which file is selected. The separate consent/opt-in behavior and importing the existing upstream provider into SkillClaw still need a follow-up design rather than being treated as solved by that PR.Upper9527 commentedon Oct 21, 2026
补充一个主分支已支持的止损方式:先运行
skillclaw config claw_type none,停止/重启代理使配置生效,再按需从备份恢复 Hermes 配置。这样后续启动不会执行 Hermes adapter,适合已经手动把目标 profile 接到代理的情况。请同时显式配置 SkillClaw 的llm.api_base、llm.model_id、llm.api_key;当前 setup 不会自动导入 Hermes 上游凭据。#72 仍只涉及路径选择。完整修复还需要 profile 对应的 skills 默认目录、备份/恢复隔离以及明确的配置修改授权,继续保留本 issue。
Upper9527 commentedon Oct 21, 2026
Fixed in #102, now merged. Startup requires both an explicitly selected
hermes.config_pathandhermes.configure: true; a minimalclaw_type: hermesno longer authorizes any Hermes config write. Setup proposesHERMES_CONFIG/HERMES_HOME, persists the resolved selection, and can import literal existing upstream settings before modifying Hermes. It rejects proxy loops/unresolved secret references rather than copying those as upstream credentials.Skills defaults, doctor, backups and restore follow the same selected profile. Cross-profile/legacy global backups are not automatically restored. Unchanged configurations are not rewritten, and invalid YAML, missing upstream settings or a failed backup prevent mutation. Twelve regression cases passed; the full suite at this change passed 200 tests (1 skipped). Please rerun setup to explicitly select your intended profile; old global backups should be restored manually only after checking their target.