[HYPERSHELL-129] feat(web-console): Adding section to gateway UI with instructions for sandbox connecting

[RunItBack1127]

Summary

• Adds a section under the Connection tab called Connect to a sandbox, which provides a convenience command for the user to connect to an existing sandbox when they open it in the Gateway UI

Changes

• Adds a section in gateway-connection-steps.tsx, along with two 2 EditableField components for the sandbox name and the editor name
• Updates i18n string configs
• Adds unit tests for the frontend components, updates existing unit tests for components under the Connection tab

openshell sandbox connect <SANDBOX_NAME> --editor <vscode|cursor>

Test Plan

• make kind-web-console-up to run the local web server
• Create a new gateway and create a sandbox in the gateway
• Run openshell sandbox connect <SANDBOX_NAME> to connect to the sandbox
• Verify shell opens to Claude prompt with specified model
• All UI unit tests are passing after running pnpm --filter @openshift-online/hypershell-gateway-management-ui test:run
• Deploy to dev cluster and verify UI changes

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: 01a3f909-b9d0-4e60-acb8-0f49b835cdac

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[jsell-rh]

Amber review

Status: Complete

Verdict

COMMENT — This is a clean, well-tested UI addition that adds a "Connect to a sandbox" step to the gateway Connection tab, reusing the existing EditableCommand component and shell-quoting helper correctly, with good unit coverage. No blockers or security issues; the actionable items are a docs-link domain inconsistency, an unrelated comment deletion, and — most importantly — a material overlap with PR #210 that maintainers must sequence.

Hi, Amber here. Two-sentence summary: PR #208 adds a copyable, inline-editable openshell sandbox connect <name> --editor <vscode|cursor> step to the Connection tab, wired through the shared EditableCommand and shellArgument quoting, with matching i18n keys and unit tests. The feature is solid; my only substantive concern is coordination with PR #210, which restructures the very same Connection-tab component and test in an incompatible-if-both-merged way.

Findings

Minor — Docs link points at a Mintlify preview domain, not the canonical docs host (packages/gateway-management-ui/src/gateways/gateway-connections.ts:80-81)
The new sandboxConnectDocsUrl resolves to https://nvidia-openshell.mintlify.app/..., whereas the existing installDocsUrl uses the canonical https://docs.nvidia.com/openshell/.... A Mintlify-hosted app subdomain is typically a preview/staging surface and is more likely to move or break than the published docs host. Recommend pointing to the docs.nvidia.com equivalent for consistency and link durability. Confidence: Medium.

Minor — Unrelated comment deletion in editable-command.tsx (packages/gateway-management-ui/src/gateways/editable-command.tsx:90)
This PR removes the comment explaining why the Enter key is swallowed (it would break both the single-line layout and the shell command). That rationale is genuinely useful to future maintainers, and the deletion is unrelated to the connect-sandbox feature. Suggest restoring it (or dropping the change from this PR to keep the diff focused). Confidence: High.

Minor — New connect command quotes its positional arg; the sibling create command still does not (gateway-connections.ts:122-146)
buildSandboxConnectCommand correctly wraps both name and editor in shellArgument(...), but the pre-existing buildSandboxCreateCommand still emits a raw --name ${name}. Both are fed from the same sanitized editable field, so this is not exploitable today, but the inconsistency is worth a follow-up so the two commands quote identically. Confidence: Medium (pre-existing; not introduced here).

Nit / UX question — shared sandboxName state mirrors across the create and connect steps
Editing the "Existing sandbox name" field in the connect step also rewrites the create command above (asserted by the new "mirrors an edited sandbox name" test). This looks intentional (create then reattach to the same name), but confirm it is the desired UX rather than two independent fields. Confidence: Low.

Cross-PR coordination

I reviewed the other open PRs in openshift-online/hypershell for material (design/plan/interface/ordering) conflicts with #208. Open PRs at review time: #216, #214, #212, #211, #210, #209, #207, #206, #201, #200, #194, #189, #188, #185, #182, #179, #151, #150, #148, #135, #109, #75, #73.

Material conflict — PR #210 [HYPERSHELL-259] feat(web-console): add gateway-matched CLI installation.
#210 and #208 independently restructure the same Connection-tab component and its test, and their changes are not composable as-is:

• Both edit packages/gateway-management-ui/src/gateways/gateway-connection-steps.tsx, adding a new command block to the same <ol> of steps ([HYPERSHELL-129] feat(web-console): Adding section to gateway UI with instructions for sandbox connecting #208 appends a "Connect to a sandbox" step; [HYPERSHELL-259] feat: reconcile gateway version for CLI installation #210 prepends a version-matched "Install the OpenShell CLI" command block). This is a design/ordering decision — the combined step order of the tab is undefined until maintainers pick one.
• Both edit gateway-connection-steps.test.tsx and bump the same shared assertion container.querySelectorAll(".shiki").length from 2 — [HYPERSHELL-129] feat(web-console): Adding section to gateway UI with instructions for sandbox connecting #208 sets it to 3, [HYPERSHELL-259] feat: reconcile gateway version for CLI installation #210 sets it to 3. If both merge, the tab will render four highlighted command blocks, so the assertion must become 4; a naive merge that keeps either literal will produce a failing/incorrect test. This is a logical conflict, not a textual one.
• Both add builders + tests to gateway-connections.ts / gateway-connections.test.ts and both add keys to messages.ts / components/web-console/locales/en.json. Additionally, [HYPERSHELL-259] feat: reconcile gateway version for CLI installation #210 repurposes the shared connectionInstallLink message (from "Install the OpenShell CLI" to "View installation documentation") and removes app.gateway.serviceAccounts.manage; [HYPERSHELL-129] feat(web-console): Adding section to gateway UI with instructions for sandbox connecting #208 leaves these as-is. Whichever lands second must reconcile against the renamed/removed keys, not just merge new ones.
• Both modify editable-command.tsx ([HYPERSHELL-129] feat(web-console): Adding section to gateway UI with instructions for sandbox connecting #208 deletes a comment; [HYPERSHELL-259] feat: reconcile gateway version for CLI installation #210 adds editable-command.test.tsx and changes the component). Competing edits to the same shared component.

Decision maintainers need: choose a merge order for #208 and #210, agree on the final Connection-tab step ordering (install → setup → create → connect, or otherwise), and have the second PR rebase to (a) set the .shiki count to the true combined total (4), (b) reconcile the connectionInstallLink rename / serviceAccounts.manage removal, and (c) unify the editable-command.tsx edits.

Not material: #214 and #209 ("HYPERSHELL-112 Dashboard UI"; #214 is #209 "with adjustments" — those two duplicate each other and should be de-duplicated between their authors) touch components/web-console/locales/en.json and CLAUDE.md, but only in the dashboard area; any overlap with #208 is a routine text merge in en.json, not a design conflict. #216 and #201 are control-plane/deploy changes with no overlap in goals, interfaces, or data model with #208. No other open PR conflicts materially with #208.

Findings Summary (highest severity first)

1. [Major] Material cross-PR conflict with [HYPERSHELL-259] feat: reconcile gateway version for CLI installation #210 over the Connection-tab step layout and the shared .shiki count assertion (combined total must be 4, both PRs hardcode 3) — Cross-PR coordination
2. [Minor] Docs link uses a Mintlify preview domain instead of canonical docs.nvidia.com — Security/Config consistency (gateway-connections.ts:80-81)
3. [Minor] Unrelated deletion of the Enter-swallow rationale comment — Maintainability (editable-command.tsx:90)
4. [Minor] Connect command quotes its arg but sibling create command still does not — Consistency (gateway-connections.ts:122-146)
5. [Nit] Shared sandboxName state mirrors across create/connect steps — confirm intended UX

Convention Checklist

Convention	Result
Input validated (shell arg quoting/sanitization)	Pass
No secrets in logs or responses	Pass (N/A — no secrets handled)
Config separate from code (docs URL as constant)	Pass
i18n keys mirrored in messages.ts and en.json	Pass
Test additions are additive, not silently rewritten guarantees	Pass
PatternFly 6 / reuse shared components	Pass (reuses EditableCommand, PF Alert)
Accessible labels + new-tab link semantics	Pass

[jsell-rh]

Verdict

COMMENT — This is a clean, well-tested UI addition that adds a "Connect to a sandbox" step to the gateway Connection tab, reusing the existing EditableCommand component and shell-quoting helper correctly, with good unit coverage. No blockers or security issues; the actionable items are a docs-link domain inconsistency, an unrelated comment deletion, and — most importantly — a material overlap with PR #210 that maintainers must sequence.

Hi, Amber here. Two-sentence summary: PR #208 adds a copyable, inline-editable openshell sandbox connect <name> --editor <vscode|cursor> step to the Connection tab, wired through the shared EditableCommand and shellArgument quoting, with matching i18n keys and unit tests. The feature is solid; my only substantive concern is coordination with PR #210, which restructures the very same Connection-tab component and test in an incompatible-if-both-merged way.

Findings

Minor — Docs link points at a Mintlify preview domain, not the canonical docs host (packages/gateway-management-ui/src/gateways/gateway-connections.ts:80-81)
The new sandboxConnectDocsUrl resolves to https://nvidia-openshell.mintlify.app/..., whereas the existing installDocsUrl uses the canonical https://docs.nvidia.com/openshell/.... A Mintlify-hosted app subdomain is typically a preview/staging surface and is more likely to move or break than the published docs host. Recommend pointing to the docs.nvidia.com equivalent for consistency and link durability. Confidence: Medium.

Minor — Unrelated comment deletion in editable-command.tsx (packages/gateway-management-ui/src/gateways/editable-command.tsx:90)
This PR removes the comment explaining why the Enter key is swallowed (it would break both the single-line layout and the shell command). That rationale is genuinely useful to future maintainers, and the deletion is unrelated to the connect-sandbox feature. Suggest restoring it (or dropping the change from this PR to keep the diff focused). Confidence: High.

Minor — New connect command quotes its positional arg; the sibling create command still does not (gateway-connections.ts:122-146)
buildSandboxConnectCommand correctly wraps both name and editor in shellArgument(...), but the pre-existing buildSandboxCreateCommand still emits a raw --name ${name}. Both are fed from the same sanitized editable field, so this is not exploitable today, but the inconsistency is worth a follow-up so the two commands quote identically. Confidence: Medium (pre-existing; not introduced here).

Nit / UX question — shared sandboxName state mirrors across the create and connect steps
Editing the "Existing sandbox name" field in the connect step also rewrites the create command above (asserted by the new "mirrors an edited sandbox name" test). This looks intentional (create then reattach to the same name), but confirm it is the desired UX rather than two independent fields. Confidence: Low.

Cross-PR coordination

I reviewed the other open PRs in openshift-online/hypershell for material (design/plan/interface/ordering) conflicts with #208. Open PRs at review time: #216, #214, #212, #211, #210, #209, #207, #206, #201, #200, #194, #189, #188, #185, #182, #179, #151, #150, #148, #135, #109, #75, #73.

Material conflict — PR #210 [HYPERSHELL-259] feat(web-console): add gateway-matched CLI installation.
#210 and #208 independently restructure the same Connection-tab component and its test, and their changes are not composable as-is:

• Both edit packages/gateway-management-ui/src/gateways/gateway-connection-steps.tsx, adding a new command block to the same <ol> of steps (#208 appends a "Connect to a sandbox" step; #210 prepends a version-matched "Install the OpenShell CLI" command block). This is a design/ordering decision — the combined step order of the tab is undefined until maintainers pick one.
• Both edit gateway-connection-steps.test.tsx and bump the same shared assertion container.querySelectorAll(".shiki").length from 2 — #208 sets it to 3, #210 sets it to 3. If both merge, the tab will render four highlighted command blocks, so the assertion must become 4; a naive merge that keeps either literal will produce a failing/incorrect test. This is a logical conflict, not a textual one.
• Both add builders + tests to gateway-connections.ts / gateway-connections.test.ts and both add keys to messages.ts / components/web-console/locales/en.json. Additionally, #210 repurposes the shared connectionInstallLink message (from "Install the OpenShell CLI" to "View installation documentation") and removes app.gateway.serviceAccounts.manage; #208 leaves these as-is. Whichever lands second must reconcile against the renamed/removed keys, not just merge new ones.
• Both modify editable-command.tsx (#208 deletes a comment; #210 adds editable-command.test.tsx and changes the component). Competing edits to the same shared component.

Decision maintainers need: choose a merge order for #208 and #210, agree on the final Connection-tab step ordering (install → setup → create → connect, or otherwise), and have the second PR rebase to (a) set the .shiki count to the true combined total (4), (b) reconcile the connectionInstallLink rename / serviceAccounts.manage removal, and (c) unify the editable-command.tsx edits.

Not material: #214 and #209 ("HYPERSHELL-112 Dashboard UI"; #214 is #209 "with adjustments" — those two duplicate each other and should be de-duplicated between their authors) touch components/web-console/locales/en.json and CLAUDE.md, but only in the dashboard area; any overlap with #208 is a routine text merge in en.json, not a design conflict. #216 and #201 are control-plane/deploy changes with no overlap in goals, interfaces, or data model with #208. No other open PR conflicts materially with #208.

Findings Summary (highest severity first)

1. [Major] Material cross-PR conflict with #210 over the Connection-tab step layout and the shared .shiki count assertion (combined total must be 4, both PRs hardcode 3) — Cross-PR coordination
2. [Minor] Docs link uses a Mintlify preview domain instead of canonical docs.nvidia.com — Security/Config consistency (gateway-connections.ts:80-81)
3. [Minor] Unrelated deletion of the Enter-swallow rationale comment — Maintainability (editable-command.tsx:90)
4. [Minor] Connect command quotes its arg but sibling create command still does not — Consistency (gateway-connections.ts:122-146)
5. [Nit] Shared sandboxName state mirrors across create/connect steps — confirm intended UX

Convention Checklist

Convention	Result
Input validated (shell arg quoting/sanitization)	Pass
No secrets in logs or responses	Pass (N/A — no secrets handled)
Config separate from code (docs URL as constant)	Pass
i18n keys mirrored in messages.ts and en.json	Pass
Test additions are additive, not silently rewritten guarantees	Pass
PatternFly 6 / reuse shared components	Pass (reuses EditableCommand, PF Alert)
Accessible labels + new-tab link semantics	Pass

[jsell-rh]

[Minor] Docs link uses a preview domain. sandboxConnectDocsUrl points at nvidia-openshell.mintlify.app, a Mintlify-hosted preview surface, while the sibling installDocsUrl (line 77-78) uses the canonical docs.nvidia.com/openshell/.... Preview subdomains are more likely to move/break. Recommend the canonical docs.nvidia.com equivalent for durability and consistency.

[jsell-rh]

[Minor] Unrelated comment removal. This PR drops the comment that explained why Enter is swallowed (a newline would break both the single-line layout and the shell command). That rationale is useful and the deletion is unrelated to the connect-sandbox feature — suggest restoring it or leaving it out of this PR to keep the diff focused.

[jsell-rh]

[Major] Cross-PR conflict with #210. #210 also bumps this shared .shiki count from 2 to 3 (it prepends a version-matched install command block); #208 bumps it to 3 for the new connect step. If both merge, the tab renders four highlighted command blocks, so this assertion must become 4 — a naive merge that keeps 3 will be wrong. Maintainers should pick a merge order and have the second PR set the true combined total and reconcile the Connection-tab step ordering. See the Cross-PR coordination section of the review.