added ruff and ty rules as well as cleaned up the PR for the same.

🚨 CRITICAL Supply Chain Risk Detected

This PR contains a pattern that has been used in real supply chain attacks. A maintainer must review the flagged code carefully before merging.

🚨 CRITICAL: Install-hook file added or modified

These files can execute code during package installation or interpreter startup.

Files:

hermes_cli/setup.py

Scanner only fires on high-signal indicators: .pth files, base64+exec/eval combos, subprocess with encoded commands, or install-hook files. Low-signal warnings were removed intentionally — if you're seeing this comment, the finding is worth inspecting.

🚨 CRITICAL Supply Chain Risk Detected

This PR contains a pattern that has been used in real supply chain attacks. A maintainer must review the flagged code carefully before merging.

🚨 CRITICAL: Install-hook file added or modified

These files can execute code during package installation or interpreter startup.

Files:

hermes_cli/setup.py
skills/productivity/google-workspace/scripts/setup.py

Scanner only fires on high-signal indicators: .pth files, base64+exec/eval combos, subprocess with encoded commands, or install-hook files. Low-signal warnings were removed intentionally — if you're seeing this comment, the finding is worth inspecting.

🚨 CRITICAL Supply Chain Risk Detected

This PR contains a pattern that has been used in real supply chain attacks. A maintainer must review the flagged code carefully before merging.

🚨 CRITICAL: Install-hook file added or modified

These files can execute code during package installation or interpreter startup.

Files:

hermes_cli/setup.py
skills/productivity/google-workspace/scripts/setup.py

Scanner only fires on high-signal indicators: .pth files, base64+exec/eval combos, subprocess with encoded commands, or install-hook files. Low-signal warnings were removed intentionally — if you're seeing this comment, the finding is worth inspecting.

🚨 CRITICAL Supply Chain Risk Detected

This PR contains a pattern that has been used in real supply chain attacks. A maintainer must review the flagged code carefully before merging.

🚨 CRITICAL: Install-hook file added or modified

These files can execute code during package installation or interpreter startup.

Files:

hermes_cli/setup.py
skills/productivity/google-workspace/scripts/setup.py

Scanner only fires on high-signal indicators: .pth files, base64+exec/eval combos, subprocess with encoded commands, or install-hook files. Low-signal warnings were removed intentionally — if you're seeing this comment, the finding is worth inspecting.

Reviewed the flagged files.

I don’t see supply-chain payload indicators in these changes:

• no .pth file
• no base64 + exec/eval
• no obfuscated subprocess payload
• no setup() / cmdclass packaging install hook

hermes_cli/setup.py appears to be the interactive Hermes setup wizard, not Python package installation machinery.
skills/productivity/google-workspace/scripts/setup.py is a manually-invoked Google OAuth helper script.

That said, the filename-based scanner is right to force maintainer review here. These filenames are high-signal in package-install contexts, and both should be eyeballed before merge.

One non-supply-chain issue worth checking: the Google OAuth scope extraction change appears to discard the raw callback URL before trying to read scope, so granted-scope persistence may have regressed.

Recommendation:

1. Maintainer review/acknowledge these two files.
2. Consider renaming helper scripts away from setup.py where possible, e.g. google_oauth_setup.py, to avoid future install-hook false positives.

Concrete implementation offer

The design judgment in #14424 that I would build on is the move to providers/<name>.py profiles as the declaration point for identity, endpoints, fetch_models(), fallback models, headers, and provider quirks. The api_mode taxonomy (chat_completions, codex_responses, anthropic_messages, bedrock_converse, copilot_acp) and auth_type taxonomy (API key, OAuth, Copilot, AWS SDK, external process) mean an operator-facing inventory command can ask the profile registry what exists instead of rediscovering it through transport/config branches.

After #14424 lands, I would be happy to take a follow-up PR for three non-interactive commands, each roughly 50-150 LOC and built entirely on that substrate:

• hermes models list [--provider=NAME] [--json] — enumerate models from provider.fetch_models() for one or all configured providers, then fall back to fallback_models.
• hermes models status [--provider=NAME] — per model: configured, auth state, and last test result if Hermes has one recorded.
• hermes providers list [--json] — list the 30 profiles with auth state, redacted key/env state, base_url, and models_url.

Sketch of the shape I have in mind:

def build_models_payload(provider: str | None = None) -> dict[str, object]:
    profiles = [get_provider_profile(provider)] if provider else list_providers()
    rows = []
    for profile in filter(None, profiles):
        state = resolve_provider_state(profile)
        if not state.configured:
            continue
        model_ids = profile.fetch_models(api_key=state.api_key) or list(profile.fallback_models)
        rows.append({
            "provider": profile.name,
            "auth_state": state.auth_state,
            "models": [{"id": m, "configured": is_configured(profile.name, m)} for m in model_ids],
        })
    return {"schema_version": 1, "providers": rows}

@pytest.fixture
def demo_provider(monkeypatch):
    profile = ProviderProfile(name="demo", base_url="https://demo.test/v1")
    monkeypatch.setattr(profile, "fetch_models", lambda **_: ["demo/model-a"])
    return profile

Issue close-out map I would propose:

• [Feature]: /models slash command for listing available models #3500: models list; /models can reuse the same inventory/formatter.
• [Feature]: Dynamic Model Discovery and Filtering for Built-in Providers #13055: models list; live discovery comes from fetch_models() with fallback models.
• Make providers the single source of truth for model registry #16622: providers list; exposes the provider registry as the operational source of truth.
• [Feature]: Model allowlist — let users control which providers appear in /model list #16608: models list and models status, if the follow-up applies model.allowlist before output and reports filtered/unconfigured entries.

Want me to open the follow-up PR against master once #14424 merges, or against this branch as a stacked PR?

Context: I maintain the nclawzero/* distro stack and contribute upstream across the claw-family ecosystem — openclaw/openclaw (PR #70224 merged), zeroclaw-labs/zeroclaw (multiple PRs in flight, several APPROVED). Happy to coordinate the follow-up so it lands in the order/shape that fits your maintainer plan.

Concrete implementation offer

The design judgment in #14424 that I would build on is the move to providers/<name>.py profiles as the declaration point for identity, endpoints, fetch_models(), fallback models, headers, and provider quirks. The api_mode taxonomy (chat_completions, codex_responses, anthropic_messages, bedrock_converse, copilot_acp) and auth_type taxonomy (API key, OAuth, Copilot, AWS SDK, external process) mean an operator-facing inventory command can ask the profile registry what exists instead of rediscovering it through transport/config branches.

After #14424 lands, I would be happy to take a follow-up PR for three non-interactive commands, each roughly 50-150 LOC and built entirely on that substrate:

• hermes models list [--provider=NAME] [--json] — enumerate models from provider.fetch_models() for one or all configured providers, then fall back to fallback_models.
• hermes models status [--provider=NAME] — per model: configured, auth state, and last test result if Hermes has one recorded.
• hermes providers list [--json] — list the 30 profiles with auth state, redacted key/env state, base_url, and models_url.

Sketch of the shape I have in mind:

def build_models_payload(provider: str | None = None) -> dict[str, object]:
    profiles = [get_provider_profile(provider)] if provider else list_providers()
    rows = []
    for profile in filter(None, profiles):
        state = resolve_provider_state(profile)
        if not state.configured:
            continue
        model_ids = profile.fetch_models(api_key=state.api_key) or list(profile.fallback_models)
        rows.append({
            "provider": profile.name,
            "auth_state": state.auth_state,
            "models": [{"id": m, "configured": is_configured(profile.name, m)} for m in model_ids],
        })
    return {"schema_version": 1, "providers": rows}

@pytest.fixture
def demo_provider(monkeypatch):
    profile = ProviderProfile(name="demo", base_url="https://demo.test/v1")
    monkeypatch.setattr(profile, "fetch_models", lambda **_: ["demo/model-a"])
    return profile

Issue close-out map I would propose:

• [Feature]: /models slash command for listing available models #3500: models list; /models can reuse the same inventory/formatter.
• [Feature]: Dynamic Model Discovery and Filtering for Built-in Providers #13055: models list; live discovery comes from fetch_models() with fallback models.
• Make providers the single source of truth for model registry #16622: providers list; exposes the provider registry as the operational source of truth.
• [Feature]: Model allowlist — let users control which providers appear in /model list #16608: models list and models status, if the follow-up applies model.allowlist before output and reports filtered/unconfigured entries.

Want me to open the follow-up PR against master once #14424 merges, or against this branch as a stacked PR?

---

Context: I maintain the nclawzero/* distro stack and contribute upstream across the claw-family ecosystem — openclaw/openclaw (PR #70224 merged), zeroclaw-labs/zeroclaw (multiple PRs in flight, several APPROVED). Happy to coordinate the follow-up so it lands in the order/shape that fits your maintainer plan.

Hey @perlowja, that sounds awesome! I’d love to discuss this further to ensure it doesn’t get overlooked. Can we move to Discord? I’m kxee there.

Hey @kxee — happy to coordinate but let's do it over email rather than Discord. Drop a desired-plan note to jperlow@gmail.com (stacking-vs-master-after, target merge order, scope-creep to avoid, anything you want to gate the follow-up on) and we'll go from there.

Reference for the docs surface I have in flight: #15214 — docs(providers): Together/Groq/Perplexity cookbook via custom_providers on my fork. Once #14424 lands, that cookbook re-roots against your providers/<name>.py profile structure rather than the current custom_providers shape. Useful as the doc pattern that wraps your implementation surface, and a sanity check that the operator-facing story stays coherent end-to-end.

To be clear: your #14424 is the architectural basis. The CLI follow-ups (hermes models list/status, hermes providers list) sit on top of ProviderProfile, the registry, and fetch_models() exactly as you've defined them — I'm not proposing any reshape to your work, just consuming it. Same posture on the issue close-out map; I'd want your read on the close-out scope before claiming any of those issues.

Talk soon.