Repository navigation
Conversation
Resolve conflict in onboard.ts: adopt upstream execOpenShell() helper while preserving policy-proxy routing via providerBaseUrl. Made-with: Cursor
Collaborator
|
Hey @ericksoa — just circling back on this one. I know you've got a few PRs open here (thanks for all the contributions, by the way!). Things have moved pretty quickly in the repo since this was first submitted — new CI pipeline, additional features, etc. Could you rebase this branch against the latest main so we can evaluate it cleanly? Would love to take a fresh look at the custom build endpoint settings. Thanks! |
Member
Author
|
Superseded — inference provider configuration is now handled by the blueprint system in onboard. |
2 tasks done
Closed
9 of 10 tasks
6 tasks done
prekshivyas
added a commit
to ColinM-sys/NemoClaw
that referenced
this pull request
Apr 16, 2026
…exercised CodeRabbit correctly flagged that swapping on stat NVIDIA#1 caused readFileSync to see the live PID and exit via isProcessAlive — unlinkIfInodeMatches was never called. Move the swap to just before stat NVIDIA#2 (inside unlinkIfInodeMatches): stat NVIDIA#1 reads the original stale inode, readFileSync sees the dead PID, isProcessAlive returns false, stale-cleanup runs, and stat NVIDIA#2 sees the new inode and skips the unlink. Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
5 tasks done
prekshivyas
added a commit
to ColinM-sys/NemoClaw
that referenced
this pull request
Apr 16, 2026
…exercised CodeRabbit correctly flagged that swapping on stat NVIDIA#1 caused readFileSync to see the live PID and exit via isProcessAlive — unlinkIfInodeMatches was never called. Move the swap to just before stat NVIDIA#2 (inside unlinkIfInodeMatches): stat NVIDIA#1 reads the original stale inode, readFileSync sees the dead PID, isProcessAlive returns false, stale-cleanup runs, and stat NVIDIA#2 sees the new inode and skips the unlink. Use write-to-temp + rename instead of unlink + recreate to guarantee a different inode even on tmpfs/overlayfs which can reuse inodes. Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
6 of 13 tasks
4 tasks done
jyaunches
pushed a commit
that referenced
this pull request
Apr 20, 2026
- Remove unused getForwardList() call from getActiveSandboxSessions — only pgrep/ps is needed for SSH session detection (warning #1) - Consolidate double-prompt in sandboxDestroy into single enriched confirmation prompt (warning #2) - Remove noisy cleanupGatewayAfterLastSandbox forward check that would always fire due to dashboard forward (warning #3) - Use word-boundary regex in parseSshProcesses to prevent false positives when sandbox names share prefixes (warning #4) - Export SessionClassification as named interface (suggestion #1) - Use cross-platform ps -axo instead of Linux-only pgrep -a for macOS compatibility (suggestion #2) - Add forwardCount to SessionClassification for future consumers - Add tests for word-boundary matching edge cases
This was referenced Apr 23, 2026
6 tasks done
3 of 6 tasks
This was referenced Apr 27, 2026
cv
added a commit
that referenced
this pull request
Apr 28, 2026
) ## Summary NemoClaw's sandbox create stream only recognized the legacy Docker builder format, so BuildKit output would not be treated as active build progress once OpenShell emits it. This adds BuildKit progress markers to the same parser path as the existing legacy builder output. It keeps the current legacy behavior and makes `#1 [internal] ...`, `#2 CACHED`, and `#3 DONE ...` visible as build progress. ## Changes - `src/lib/sandbox-create-stream.ts`: recognize BuildKit step and completion lines while tracking the build phase. - `src/lib/sandbox-create-stream.test.ts`: cover BuildKit progress output and verify it is streamed to the user. ## Testing - `npm run build:cli` passed - `npm run typecheck:cli` passed - `npm test -- src/lib/sandbox-create-stream.test.ts` passed - `npm test` was also attempted. The full suite is not green on current main in this environment; failures are in existing installer/onboard/legacy-guard tests outside this change. ## Evidence it works The new focused test feeds BuildKit-style output into `streamSandboxCreate` and verifies that the lines are logged, collected in output, and mark sandbox creation as having seen progress. Fixes #2311 Signed-off-by: Deepak Jain <deepujain@gmail.com> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved detection and display of BuildKit and upload progress so progress markers and completion states are recognized reliably. * **Refactor** * Centralized progress-detection logic for more consistent handling of build and upload output. * **Tests** * Added a test ensuring BuildKit-formatted progress lines are captured, included in output, and reported to the log callback. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Signed-off-by: Deepak Jain <deepujain@gmail.com> Co-authored-by: Carlos Villela <cvillela@nvidia.com>
cv
added a commit
that referenced
this pull request
Apr 28, 2026
) ## Summary NemoClaw's sandbox create stream only recognized the legacy Docker builder format, so BuildKit output would not be treated as active build progress once OpenShell emits it. This adds BuildKit progress markers to the same parser path as the existing legacy builder output. It keeps the current legacy behavior and makes `#1 [internal] ...`, `#2 CACHED`, and `#3 DONE ...` visible as build progress. ## Changes - `src/lib/sandbox-create-stream.ts`: recognize BuildKit step and completion lines while tracking the build phase. - `src/lib/sandbox-create-stream.test.ts`: cover BuildKit progress output and verify it is streamed to the user. ## Testing - `npm run build:cli` passed - `npm run typecheck:cli` passed - `npm test -- src/lib/sandbox-create-stream.test.ts` passed - `npm test` was also attempted. The full suite is not green on current main in this environment; failures are in existing installer/onboard/legacy-guard tests outside this change. ## Evidence it works The new focused test feeds BuildKit-style output into `streamSandboxCreate` and verifies that the lines are logged, collected in output, and mark sandbox creation as having seen progress. Fixes #2311 Signed-off-by: Deepak Jain <deepujain@gmail.com> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved detection and display of BuildKit and upload progress so progress markers and completion states are recognized reliably. * **Refactor** * Centralized progress-detection logic for more consistent handling of build and upload output. * **Tests** * Added a test ensuring BuildKit-formatted progress lines are captured, included in output, and reported to the log callback. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Signed-off-by: Deepak Jain <deepujain@gmail.com> Co-authored-by: Carlos Villela <cvillela@nvidia.com>
This was referenced Jun 26, 2026
This was referenced Jun 28, 2026
cjagwani
added a commit
that referenced
this pull request
Jul 2, 2026
… paths (#6188) Address advisor PRA-1 / PRA-7 and CodeRabbit Major #2: - backupStateFile now returns { outcome, unreachable } instead of a bare string enum. Transport-level SSH failures (exit 255, signal kill, spawn error) during state-file backup set unreachable=true. The caller in backupSandboxState propagates this to the outer BackupResult.unreachable so NEMOCLAW_SKIP_UNREACHABLE_SANDBOX_BACKUP=1 activates for state-file failures, not only the initial dir probe. - getSshConfig-null branch in backupSandboxState now returns unreachable=true. For a sandbox already confirmed running (the maintenance.ts loop only reaches BackupResult.unreachable for running sandboxes), an ssh-config lookup failure is transport-level. Addresses CodeRabbit's Major finding at sandbox.ts:1128-1141. Both branches now feed the same skip path already exercised by the initial dir probe. Propagation is covered by manual E2E for the running-sandbox-goes-unreachable-mid-loop case; unit tests would require heavy spawnSync mocking that this PR does not introduce. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Signed-off-by: Charan Jagwani <cjagwani@nvidia.com>
This was referenced Jul 2, 2026
Merged
12 of 22 tasks
This was referenced Jul 6, 2026
9 tasks done
cv
pushed a commit
that referenced
this pull request
Jul 6, 2026
…board dcode identity failure (#6343) ## Summary Fixes two E2E-harness problems surfaced by the E2E dispatch on `main`: 1. **e2e-live source require hook** — the `hermes-inference-switch` live suite (added in #6335) failed at collection with `Cannot find module '../runner'` because the `e2e-live` Vitest project never loaded the typed-source require hook. 2. **cloud-onboard observability** — the cloud-experimental check-04 (added in #6332) fails on `main` with `could not read initial dcode identity`, but the real `dcode identity` error is captured into a shell var and discarded, so it can't be diagnosed. ## Changes - `vitest.config.ts`: add `setupFiles: ["test/helpers/onboard-script-mocks.cjs"]` to the `e2e-live` project (mirrors `cli`). Registers the typed-source `.ts` require hook **in-process** — deliberately not via `env.NODE_OPTIONS`, so `--require` never leaks into the real CLI subprocesses live tests spawn. - `test/e2e/e2e-cloud-experimental/checks/04-deepagents-code-fresh-reonboard.sh`: on both `dcode identity` reads, print the captured stdout+stderr to stdout (so it lands in `result.json`) before `fail`. No change to pass/fail logic — only makes the existing failure observable. ### Root cause — #1 (fixed here) `hermes-inference-switch` is the first `e2e-live` suite to import a deep `src` graph — its helpers import `src/lib/inference/config.ts`, which transitively loads `ollama-runtime-context.ts`'s runtime `require("../runner")`. Without the require hook, Node's native CJS resolver can't resolve the extensionless `.ts` → suite throws at collection (`0 tests`, ~37s). Only this suite hit it; others drive the CLI as a subprocess and import only fixtures. `runner.ts` has no circular dependency on the inference graph, so the in-process hook resolves it fully. ### Root cause — #2 (observability only; product root cause pending) `cloud-onboard` was green on `main` through 2026-07-06 00:56 UTC and failed on the first main E2E after #6332 landed (19:50 UTC) — #6332 added check-04, which has never passed on main. `dcode identity` is the NemoClaw wrapper (`agents/langchain-deepagents-code/dcode-wrapper.sh`); its identity path returns 0 in isolation and #6332 did not modify it, so the non-zero exit is a runtime condition in #6332's new "recreate/verify live identity" onboarding flow. That can't be pinned without the swallowed stderr — which this change surfaces. Product root cause is for the #6332 author to fix once the next run shows the real error. ## Type of Change - [x] Code change (feature, bug fix, or refactor) ## Quality Gates - [x] Existing tests cover changed behavior — justification: both changes are E2E-harness config/diagnostics. #1: the `e2e-live` suites exercise the hook — verified the previously-failing `hermes-inference-switch` suite now collects and all `e2e-live` suites report 0 collection errors, and the full `e2e-all` dispatch ran the switch job (hosted) green. #2: pure diagnostic output; no pass/fail change. - [x] Docs not applicable — justification: internal test-harness config/diagnostics; no user-facing behavior. - [x] Sensitive paths changed (onboarding/inference/runner adjacent via test config) - [x] Sensitive-path review completed or maintainer-approved waiver recorded — justification: changes are confined to Vitest test-runner setup (`vitest.config.ts`) and an E2E diagnostic print; no product runtime code path is altered. The require hook is in-process only and does not touch product CLI subprocesses. ## Verification - [x] PR description includes the DCO sign-off declaration and every commit appears as `Verified` in GitHub - [x] Normal `pre-commit`, `commit-msg`, and `pre-push` hooks passed — note: `pre-push` `tsc-cli` skipped for a pre-existing local-only `noImplicitAny` false-positive in `test/helpers/mcp-lifecycle-lock-properties.ts` and `src/lib/state/mcp-lifecycle-lock-identity.test.ts` (unrelated to this diff); CI `tsc-cli` covers it. Check-04 passed `bash -n` and the `shellcheck`/`shfmt` pre-commit hooks. - [x] Targeted behavior tests pass — command/result: `NEMOCLAW_RUN_LIVE_E2E=1 npx vitest list --project e2e-live` → switch suite collects; whole project 0 collection errors (before the fix it reproduced `Cannot find module '../runner'`). Full `e2e-all` dispatch on this branch ran `hermes-inference-switch (hosted)` green. - [x] No secrets, API keys, or credentials committed --- Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved reliability of live end-to-end test runs by loading the required hook inside the test process, avoiding leakage into real CLI subprocesses. * Made identity checks in sandboxed cloud experimental flows more robust, with clearer diagnostics when identity lookup fails. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jul 8, 2026
Hadar301
pushed a commit
to Hadar301/NemoClaw-OpenShift
that referenced
this pull request
Jul 12, 2026
…board dcode identity failure (NVIDIA#6343) ## Summary Fixes two E2E-harness problems surfaced by the E2E dispatch on `main`: 1. **e2e-live source require hook** — the `hermes-inference-switch` live suite (added in NVIDIA#6335) failed at collection with `Cannot find module '../runner'` because the `e2e-live` Vitest project never loaded the typed-source require hook. 2. **cloud-onboard observability** — the cloud-experimental check-04 (added in NVIDIA#6332) fails on `main` with `could not read initial dcode identity`, but the real `dcode identity` error is captured into a shell var and discarded, so it can't be diagnosed. ## Changes - `vitest.config.ts`: add `setupFiles: ["test/helpers/onboard-script-mocks.cjs"]` to the `e2e-live` project (mirrors `cli`). Registers the typed-source `.ts` require hook **in-process** — deliberately not via `env.NODE_OPTIONS`, so `--require` never leaks into the real CLI subprocesses live tests spawn. - `test/e2e/e2e-cloud-experimental/checks/04-deepagents-code-fresh-reonboard.sh`: on both `dcode identity` reads, print the captured stdout+stderr to stdout (so it lands in `result.json`) before `fail`. No change to pass/fail logic — only makes the existing failure observable. ### Root cause — rh-ai-quickstart#1 (fixed here) `hermes-inference-switch` is the first `e2e-live` suite to import a deep `src` graph — its helpers import `src/lib/inference/config.ts`, which transitively loads `ollama-runtime-context.ts`'s runtime `require("../runner")`. Without the require hook, Node's native CJS resolver can't resolve the extensionless `.ts` → suite throws at collection (`0 tests`, ~37s). Only this suite hit it; others drive the CLI as a subprocess and import only fixtures. `runner.ts` has no circular dependency on the inference graph, so the in-process hook resolves it fully. ### Root cause — NVIDIA#2 (observability only; product root cause pending) `cloud-onboard` was green on `main` through 2026-07-06 00:56 UTC and failed on the first main E2E after NVIDIA#6332 landed (19:50 UTC) — NVIDIA#6332 added check-04, which has never passed on main. `dcode identity` is the NemoClaw wrapper (`agents/langchain-deepagents-code/dcode-wrapper.sh`); its identity path returns 0 in isolation and NVIDIA#6332 did not modify it, so the non-zero exit is a runtime condition in NVIDIA#6332's new "recreate/verify live identity" onboarding flow. That can't be pinned without the swallowed stderr — which this change surfaces. Product root cause is for the NVIDIA#6332 author to fix once the next run shows the real error. ## Type of Change - [x] Code change (feature, bug fix, or refactor) ## Quality Gates - [x] Existing tests cover changed behavior — justification: both changes are E2E-harness config/diagnostics. rh-ai-quickstart#1: the `e2e-live` suites exercise the hook — verified the previously-failing `hermes-inference-switch` suite now collects and all `e2e-live` suites report 0 collection errors, and the full `e2e-all` dispatch ran the switch job (hosted) green. NVIDIA#2: pure diagnostic output; no pass/fail change. - [x] Docs not applicable — justification: internal test-harness config/diagnostics; no user-facing behavior. - [x] Sensitive paths changed (onboarding/inference/runner adjacent via test config) - [x] Sensitive-path review completed or maintainer-approved waiver recorded — justification: changes are confined to Vitest test-runner setup (`vitest.config.ts`) and an E2E diagnostic print; no product runtime code path is altered. The require hook is in-process only and does not touch product CLI subprocesses. ## Verification - [x] PR description includes the DCO sign-off declaration and every commit appears as `Verified` in GitHub - [x] Normal `pre-commit`, `commit-msg`, and `pre-push` hooks passed — note: `pre-push` `tsc-cli` skipped for a pre-existing local-only `noImplicitAny` false-positive in `test/helpers/mcp-lifecycle-lock-properties.ts` and `src/lib/state/mcp-lifecycle-lock-identity.test.ts` (unrelated to this diff); CI `tsc-cli` covers it. Check-04 passed `bash -n` and the `shellcheck`/`shfmt` pre-commit hooks. - [x] Targeted behavior tests pass — command/result: `NEMOCLAW_RUN_LIVE_E2E=1 npx vitest list --project e2e-live` → switch suite collects; whole project 0 collection errors (before the fix it reproduced `Cannot find module '../runner'`). Full `e2e-all` dispatch on this branch ran `hermes-inference-switch (hosted)` green. - [x] No secrets, API keys, or credentials committed --- Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved reliability of live end-to-end test runs by loading the required hook inside the test process, avoiding leakage into real CLI subprocesses. * Made identity checks in sandboxed cloud experimental flows more robust, with clearer diagnostics when identity lookup fails. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
8 tasks
cv
added a commit
that referenced
this pull request
Nov 4, 2026
…4192) ## Failure The GPU autoscaling example has no way to load the chart's GPUs through the agents, which is what makes its autoscaler scale. #14009 had load clients, but they sent each prompt with `kubectl exec` into the sandbox pods, around the gateway's authentication, and read pod names and runtime IDs from NemoClaw's `terraform.tfstate`. With the `development` profile that example uses, nobody but NemoClaw can authenticate to the gateway, so no supported client could reach the agents. ## Decision Follows #14191 (merged), on which this was stacked. - `examples/kubernetes/gpu-autoscaling/load.sh`, a Bash script with the OpenShell CLI, `curl` and `jq`. It reads `nemoclaw apply -o json` and sends `PROMPTS` prompts across the agents, at most `CONCURRENCY` at a time through `xargs -P`, then prints how many it sent and how many replied, the median, 95th-percentile and longest latency overall and per sandbox, up to 10 failures, and one reply per sandbox. It exits nonzero if any request failed. Each sandbox takes one of the two paths that need no state files or `kubectl exec`: - **Hermes's API server**, when apply lists an `api` interface and an `api` service URL for the sandbox: OpenAI chat completions to `serviceUrls.SANDBOX.api`, through the gateway's port forward and with its client certificate. The script reads the interface token once, with `openshell sandbox exec … cat` and the reported `tokenPath`, into a private temporary file. - **`fabric-agent-ctl invoke`** for any other sandbox, such as OpenClaw or Deep Agents, through `openshell sandbox exec` with `agents.SANDBOX.runtimeId` (#14186). - `two-runtimes.yaml`: a Hermes sandbox on the chart's vLLM release and an OpenClaw sandbox on its Ollama release, the two that `install-two-runtimes.sh` installs (#14191). It uses the `oidc` profile, and declares Hermes's `api` interface with a `serviceExposures` entry using `BEARER_PASSTHROUGH`, because OpenShell's default `STRIP` drops the token Hermes checks. Its Envoy Service names are the ones Envoy Gateway v1.8.3 created for those Gateways on kind; it shortens a Gateway's name to 48 characters before the hash. - `README.md`: **Drive Load Through the Agents**, with the apply and run commands, the variables, and the limits: the gateway's one CPU for `sandbox exec`, Fabric's one invocation at a time per runtime, Hermes's 10 concurrent runs per sandbox, what a service URL skips, and that the CLI doesn't renew a client-credentials token (NVIDIA/OpenShell#4287). From #14009's `e2e-fabric-load-test.py` and client scripts, this keeps the prompts, the per-request timeout, the success check on `result.status` and `result.output.response`, and per-sandbox counts. It leaves out the HPA polling and the stop-at-ceiling logic, which belong to the chart and `kubectl get hpa --watch`; the OpenClaw tool pinning, which edited Fabric's generated configuration inside the sandbox; and the timeline and CSV output. ## Validation - `cargo ci` on `c6a581a9cf`: all selected steps passed in 135 s; test ran 1,827 tests and lifecycle 101. `cargo test -p nemoclaw-onboarding two_runtimes` ran the new file's onboarding journey. - `shellcheck` 0.11 (`koalaman/shellcheck:stable`) on `load.sh`: no findings. - Live run on a local kind cluster (kind v0.33.0, `kindest/node:v1.37.0`, Agent Sandbox 1.0.3, linux/arm64, no GPU), with resources I created and removed afterwards: - **Model:** the chart from nemoclaw-community `cb46db83ab` installed with `helm`, with Ollama and `qwen3:0.6b` on CPU, no GPU request or node selector, no ServiceMonitor or HPA, arm64 digests for Ollama 0.40.11 and `node:22-bookworm-slim`, behind Envoy Gateway v1.8.3. Both sandboxes used its one Envoy Service, with `model: qwen3:0.6b`. - **Issuer:** Keycloak 26.4 in the cluster, at `https://<kind node IP>:30443/realms/openshell` with a test CA, so that the gateway pod and the host see the same issuer URL, with a confidential client whose service account has the admin role in a `roles` claim and audience `openshell`. The kind HCL cases' issuer serves only discovery and keys, with no token endpoint, so the OpenShell CLI can't sign in through it. - **Deployment:** `two-runtimes.yaml` with the context, issuer, endpoints, model and image digests replaced, and `openclaw` and `hermes` built for linux/arm64 and pushed to a registry on the kind network. `nemoclaw apply -o json` with the bundle from this branch succeeded, and reported `serviceUrls.user-0000.api` as `https://nc-…--user-0000--api.openshell.localhost:8080/`, both runtime IDs under `agents`, and the Hermes token path under `interfaces`. - **CLI:** the port forward and client certificate from `docs/kubernetes.md`, then `openshell gateway add … --oidc-client-id` with `OPENSHELL_OIDC_CLIENT_SECRET` (OpenShell 0.1.6): `Authenticated via client credentials`; `openshell status` showed `Authenticated (OIDC)`. - **Load:** `PROMPTS=12 CONCURRENCY=4 load.sh apply.json`: ```text Sending 12 prompts to 2 sandboxes, at most 4 at a time: user-0000: Hermes API at https://nc-…--user-0000--api.openshell.localhost:8080/ user-0001: fabric-agent-ctl invoke, runtime runtime-1793794887745-82-2 Sent 12 prompts in 238 s: 12 replied, 0 failed. Latency of replies: p50 51.9 s, p95 156 s, max 156 s. user-0000 (api): 6/6 replied; p50 16.9 s, p95 87.6 s, max 87.6 s user-0001 (invoke): 6/6 replied; p50 80.7 s, p95 156 s, max 156 s reply #1 user-0000: A Kubernetes HorizontalPodAutoscaler is a service that automatically scales its pods based on metrics. reply #2 user-0001: The current system state shows no active exec sessions or subagents, indicating no ongoing operations are in progress. To proceed, please check your system or c ``` An earlier run of 8 prompts also got 8 replies. OpenClaw's replies don't answer the prompts, likely because of `qwen3:0.6b` with OpenClaw's tools; each invocation still reported `succeeded` with a response. - **Failures:** with `TIMEOUT=5`, both requests were reported as failed (`curl: (28) Operation timed out` and `timed out after 5 s`), and the script exited 1. - Not run: GPUs, autoscaling, vLLM, NIM, and Deep Agents. The Deep Agents path is the same `fabric-agent-ctl invoke` command as OpenClaw's. - Deferred to CI: `cargo ci live-kind` and `live-docker`; the change adds no image or Kubernetes code. Co-authored-by: maggiezha <42832776+maggiezha@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Migrated from NVIDIA/openshell-openclaw-plugin#18 by @nv-kasikritc