[sergiopaniego]

Found while redeploying the openenv/* Spaces for #1296.

The script sets visibility after every upload with hf repo settings --no-private (or --private). With the current hf CLI this has two problems:

• --no-private is ignored by hf repos settings (the flag to make a repo public is --public), so the script never made a Space public. The call failed with Error: Invalid value. At least one setting must be updated. and the env was reported as failed, even though the upload had gone through. This is what happened with openenv/terminus_env, which stayed private until I ran hf repos settings --public by hand.
• The same error comes back whenever the Space already has the requested visibility, which is every redeploy of an existing Space.

The script now reads the current visibility with hf spaces info --expand=private, only calls hf repos settings when it differs, and uses --public to make a Space public.

A new test puts a fake hf on PATH and covers the four cases (already public, already private, private to public, public to private). PYTHONPATH=src:envs pytest tests/scripts/test_prepare_hf_deployment.py passes (11 tests).

This PR was prepared with AI assistance.

---

Note

Low Risk
Deployment-script-only change with new tests; no runtime app or auth logic affected.

Overview
Fixes Hugging Face Space visibility updates in prepare_hf_deployment.sh so redeploys stop failing and --public actually works with the current hf CLI.

After upload, the script now reads the Space’s current private flag via hf spaces info, and only runs hf repos settings when that state differs from --public / --private. Making a Space public uses --public instead of the ignored --no-private, avoiding the “at least one setting must be updated” error on no-op redeploys.

Adds a parametrized test with a fake hf on PATH that asserts settings are skipped when visibility already matches and that --public / --private are passed only when a change is needed.

^{Reviewed by Cursor Bugbot for commit 7991452. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Alignment Review Report

Automated Checks

• Lint: PASS — .claude/hooks/lint.sh needs uv, which wasn't available in this sandbox, so I ran the equivalent tools directly: ruff format --check, ruff check, and usort check on tests/scripts/test_prepare_hf_deployment.py (the only Python file touched) all pass. prepare_hf_deployment.sh isn't in lint.sh's scope (src/, tests/, envs/ only) and the sandbox has no shellcheck, so the shell diff wasn't linted automatically — I reviewed it manually instead (see below).
• Debug code: CLEAN — check-debug.sh only scans src/; no files touched by this PR fall in that scope, and manual inspection of the diff found no prints/breakpoints/TODOs.

Open RFCs Context

All nine open RFCs (000, 001, 002, 003, 004, 005, 006, 008 — In Review; 010, 011 — Draft) are scoped to env abstractions, MCP, rewards, rubrics, harness interception, auto-validation, and catalog discovery. None reference prepare_hf_deployment.sh, hf repo settings, or Space visibility handling, and this change doesn't touch any of those areas (no Environment/EnvClient API, no MCP, no reward/transform code, no agent-facing surface).

Verification performed

• Installed huggingface_hub locally and confirmed hf spaces info --expand=private --format json is a real, documented subcommand/flag combo, and that its live output format ({"id": "...", "private": false}) matches exactly what the new grep -q '"private": *true' check and the test's fake-hf mock assume.
• Ran tests/scripts/test_prepare_hf_deployment.py directly: all 4 new parametrized cases (already public, already private, private→public, public→private) pass. One pre-existing, unrelated test (test_prepare_hf_deployment_keeps_the_env_description_first) fails in this sandbox only because PYTHONPATH doesn't include src//envs/ — not caused by this diff.
• Confirmed $PRIVATE and the new $current_private are both plain true/false strings compared consistently with the rest of the file's existing convention (e.g. line 775's [ "$PRIVATE" = true ]).
• Confirmed the grep-based JSON parsing matches the repo's existing style: no file in this script (or elsewhere in the repo) currently uses jq for parsing hf output, so this doesn't introduce a new dependency pattern. Per the hf-cli/Hub-parity guidance in AGENTS.md/CLAUDE.md, the new call reads visibility with hf spaces info --expand=private rather than inventing custom behavior — consistent with following huggingface_hub's own CLI surface.

Tier 1: Fixes Required

None identified.

Tier 2: Alignment Discussion

Principle Conflicts

None identified. This is a deployment-tooling bug fix (scripts/, not src/openenv core) and doesn't touch the Gym-like API, MCP boundary, reward computation, container isolation, or client/server separation invariants in INVARIANTS.md.

RFC Conflicts

None identified. No open RFC covers HF Space deployment/visibility handling.

Summary

• 0 mechanical issues to fix
• 0 alignment points for human review
• 0 RFC conflicts to discuss

This is a well-scoped, well-tested bug fix: it correctly diagnoses that hf repo settings rejects no-op visibility updates, fixes it by checking current state first via a real hf spaces info call (verified against live CLI output), and backs it with a parametrized regression test covering all four visibility transitions. No concerns.

  

_{Sent by Cursor Automation: Pre-review}