Ship an independent apps/vscode/ App with manifest, source, self-contained ESM entrypoint, build/tests and README, following this repository's package conventions. Bundle a pinned backend descriptor/bootstrap for OpenVSCode; do not vendor its binary tree in Git. Reuse the existing OpenVSCode version/install knowledge, but the app owns the downloaded release and updates. A managed subprocess colocated with the target workspace is the default, not a separate Docker container with different tools/files.
Acceptance criteria:
- UI probes without mutation, shows version/hash/download/data/network disclosures, explicit install/start/stop/repair, readiness and actionable errors.
- Checksummed Linux amd64/arm64 artifacts and app-owned user data/extensions paths; no raw shell or secret export in browser. Unsupported platform/runtime fails explicitly.
- Open a chosen authorized local conversation workspace; test file edit/save and terminal command in the SAME workspace/tool environment. Do not claim path checks are OS sandboxing.
- Actual Canvas install/enable/open/edit/terminal/reload/stop/re-enable click-through recorded as animated GIF committed under .pr/ and embedded in PR description. No credentials/private files in recording.
- Real backend, real browser and Blob-bundle tests; CI workflow for this app is added if absent and green.
- Isolated acceptance stack has fresh HOME/persistence, synthetic workspace, no inherited user secrets; authenticated ngrok ingress forwards HTTP/WS and is tested externally. Provide endpoint separately from credentials.
- Release here means a reviewed, installable pinned App artifact and documented coordinate in this PR, not permission to merge/tag automatically. Avoid modifying Kanban or creating shared app runtime.
Related: existing sidecar example PR OpenHands/canvas-apps#21; it requires operator nginx and does not provide portable managed service routing.
Dependencies and sequencing
Implementation/merge prerequisites (cross-repository links are authoritative):
Readiness means design/scope accepted; implementation must wait for the triage automation to apply ready-for-dev. Dependent PRs may stack on tested prerequisite branches; they must not merge before prerequisite PRs. No issue should be closed just to bypass sequencing. One issue per PR.
This issue was created by an AI agent (OpenHands) on behalf of Graham Neubig.
Catalog migration prerequisite
Merge prerequisite (stacked implementation authorized): #530
Implement this App in OpenHands/extensions/apps/ using the conventions established by #530. Original issue history is preserved by repository transfer. Existing prerequisites remain in effect.
This dependency update was made by an AI agent (OpenHands) on behalf of Graham Neubig.
Maintainer authorization for stacked implementation
Graham Neubig explicitly authorized stacked implementation before prerequisite issues close. Dependencies above are merge-order constraints, not closed-issue requirements for implementation readiness. Please evaluate scope readiness independently; do not close prerequisite issues or waive validation. Use native GitHub stacks for same-repository PR chains and explicit links for cross-repository dependencies.
This update was made by an AI agent (OpenHands) on behalf of Graham Neubig.
Ship an independent apps/vscode/ App with manifest, source, self-contained ESM entrypoint, build/tests and README, following this repository's package conventions. Bundle a pinned backend descriptor/bootstrap for OpenVSCode; do not vendor its binary tree in Git. Reuse the existing OpenVSCode version/install knowledge, but the app owns the downloaded release and updates. A managed subprocess colocated with the target workspace is the default, not a separate Docker container with different tools/files.
Acceptance criteria:
Related: existing sidecar example PR OpenHands/canvas-apps#21; it requires operator nginx and does not provide portable managed service routing.
Dependencies and sequencing
Implementation/merge prerequisites (cross-repository links are authoritative):
Readiness means design/scope accepted; implementation must wait for the triage automation to apply ready-for-dev. Dependent PRs may stack on tested prerequisite branches; they must not merge before prerequisite PRs. No issue should be closed just to bypass sequencing. One issue per PR.
This issue was created by an AI agent (OpenHands) on behalf of Graham Neubig.
Catalog migration prerequisite
Merge prerequisite (stacked implementation authorized): #530
Implement this App in
OpenHands/extensions/apps/using the conventions established by #530. Original issue history is preserved by repository transfer. Existing prerequisites remain in effect.This dependency update was made by an AI agent (OpenHands) on behalf of Graham Neubig.
Maintainer authorization for stacked implementation
Graham Neubig explicitly authorized stacked implementation before prerequisite issues close. Dependencies above are merge-order constraints, not closed-issue requirements for implementation readiness. Please evaluate scope readiness independently; do not close prerequisite issues or waive validation. Use native GitHub stacks for same-repository PR chains and explicit links for cross-repository dependencies.
This update was made by an AI agent (OpenHands) on behalf of Graham Neubig.