Adds hydra safty guard against cli args starting with --

[ooctipus]

Description

This PR adds safty guard mechanism to hydra preset system to filter out user's -- cliargs

Type of change

• Bug fix (non-breaking change which fixes an issue)

Screenshots

Please attach before and after screenshots of the change if applicable.

Checklist

• I have read and understood the contribution guidelines
• I have run the pre-commit checks with ./isaaclab.sh --format
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• I have updated the changelog and the corresponding version in the extension's config/extension.toml file
• I have added my name to the CONTRIBUTORS.md or my name already exists there

[greptile-apps]

Greptile Summary

This PR adds a two-line safety guard in parse_overrides (hydra.py) that skips any CLI argument beginning with - before the existing Hydra categorization logic runs. This prevents non-Hydra flags like --headless or --device=cpu from being forwarded to Hydra (which would cause an error) or from being misclassified as preset selectors or global scalars.

Key points:

• The fix is logically correct: neither single- (-flag) nor double-dash (--flag) arguments are valid Hydra override syntax, so filtering both is appropriate.
• The guard is placed before the "=" not in arg branch, so it covers args both with and without = (e.g., both --headless and --device=cpu).
• Args are dropped silently — no debug log or warning is emitted. If a user accidentally passes a dash-prefixed Hydra override (e.g., -env.sim.dt=0.01), it will fail silently with no feedback.
• The PR description/title refers only to -- (double-dash) args, but the implementation uses startswith("-") which also catches single-dash args. The code comment should reflect this broader scope for clarity.
• No tests were added for the new guard, and the changelog/extension version was not updated.

Confidence Score: 4/5

• This PR is safe to merge; the guard is logically correct and prevents a concrete runtime error when non-Hydra CLI args are present.
• The two-line safety guard is minimal and correctly addresses the stated bug. No functional regressions are introduced. The only concerns are quality/clarity issues: args are dropped silently (no debug logging for failed scenarios), and a minor mismatch between PR description ("--" only) and implementation (all "-" prefixed args) needs clarification in code comments.
• No files require special attention beyond the single changed file, which has two style/clarity recommendations in the guard logic itself.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["sys.argv[1:] args"] --> B{"starts with '-'?"}
    B -->|Yes| SKIP["Skip / discard arg\nnew guard in this PR"]
    B -->|No| C{"has '='?"}
    C -->|No| GS["global_scalar\npassed to Hydra"]
    C -->|Yes| D{"key == 'presets'?"}
    D -->|Yes| GP["global_presets list"]
    D -->|No| E{"key in preset_paths?"}
    E -->|Yes| PS["preset_sel list\nREPLACE selection"]
    E -->|No| F{"key starts with preset_path + '.'?"}
    F -->|Yes| PSC["preset_scalar list\nscalar in preset path"]
    F -->|No| GS2["global_scalar\npassed to Hydra"]

Loading

_{Last reviewed commit: 6d6b08b}

[greptile-apps]

Args starting with - are silently dropped with no logging or warning. If a user accidentally prefixes a Hydra override with a dash (e.g., -env.sim.dt=0.01 instead of env.sim.dt=0.01), the override will be silently ignored with no feedback as to why it had no effect.

Consider adding a debug-level log message to help users diagnose such situations:

Suggested change

	if arg.startswith("-"):
	continue
	if arg.startswith("-"):
	# Skip non-Hydra CLI args (e.g. --headless, --device=cpu)
	continue

Adding a comment explaining this behavior would also help future maintainers understand the intent.

[greptile-apps]

The PR description and title refer to filtering -- (double-dash) CLI args, but the guard uses startswith("-"), which also filters single-dash args (e.g., -v, -e). While filtering both single- and double-dash args is correct (neither is valid Hydra override syntax), the code comment should reflect this accurately to avoid confusing future maintainers.

Consider clarifying the intent with a more precise comment:

Suggested change

	if arg.startswith("-"):
	continue
	if arg.startswith("-"):
	# Skip standard UNIX-style CLI flags (both -flag and --flag).
	# These are intended for the outer argparse layer, not for Hydra.
	continue

[AntoineRichard]

Hi @ooctipus — thanks for putting this one up! 🙏

We're doing a cleanup pass over the Isaac Lab PR backlog, which had grown past 400 open pull requests, and we're closing out the ones that have gone quiet so the queue is reviewable again.

Why this PR is being closed: Here is exactly what we found on this PR when we reviewed the backlog:

Opened	2026-03-03 (about 6 months ago)
Last commit on the branch	2026-03-03
Last activity from the author	about 6 months ago
Target branch	develop
Review status	Never reviewed by a maintainer — nobody on the team got to it. Sorry about that.
Merge status	Unknown
Size	1 commit(s), 1 file(s) changed, +2 / -0

It was picked up by the sweep because it has been open for about 6 months. It was then put in the "close" bucket because the author has been silent for about 6 months — which is the signal we used to tell apart pull requests that are still being worked on from ones that have genuinely been set aside.

We deliberately did not close pull requests that were approved and ready to land, or that were small and clearly still fixing a live bug — there were 27 of those, and we are merging them rather than closing them.

No judgement on the change itself — this is purely backlog hygiene.

If this is still wanted, please reopen it or re-submit against develop. 💚

---

🤖 This comment was drafted with AI assistance as part of a maintainer-led sweep of the Isaac Lab pull request backlog. A maintainer is behind this cleanup — but if this closure looks wrong, it may well be, so please push back and we'll take another look.