feat(workspace): add Open in VS Code action for files and folders (#2735)

[munim]

Thinking Path

• Hermes WebUI aims for near 1:1 parity with the Hermes CLI in a browser
• The workspace file browser already has Reveal in File Manager and Copy file path actions
• Developers working with local projects want to jump directly from the file browser into their editor
• VS Code is the dominant editor; it ships a code CLI on all platforms
• This PR adds an Open in VS Code action that works on macOS, Linux, and Windows, with Docker path mapping support

What Changed

api/routes.py

• New POST /api/file/open-vscode endpoint and _handle_file_open_vscode handler
• Resolves the workspace-relative path via safe_resolve (path traversal protection)
• Finds VS Code via shutil.which() first, then falls back to hardcoded common install paths:
  • macOS: /usr/local/bin/code, app bundle CLI
  • Linux: /usr/bin/code, /snap/bin/code
  • Windows: %LOCALAPPDATA%\Programs\Microsoft VS Code\bin\code.cmd, %PROGRAMFILES% user/system installs
• Returns a descriptive error if VS Code cannot be found, instead of a bare FileNotFoundError
• Reads optional vscode block from config.yaml:

  vscode:
    command: code                          # default; override with full path if needed
    host_path_prefix: /home/user/projects  # Docker: host path
    container_path_prefix: /app/workspace  # Docker: matching container path

static/ui.js

• "Open in VS Code" menu item added to _showFileContextMenu (files and folders)
• "Open in VS Code" menu item added to _showWorkspaceRootContextMenu (workspace root)
• Follows existing pattern: var(--hover-bg), (err.message||err) guard, same style as Reveal item

static/i18n.js

• open_in_vscode and open_in_vscode_failed keys added with full translations in all 10 locales: en, it, ja, ru, es, de, zh-CN, zh-TW, pt, ko

tests/test_2735_open_in_vscode.py

• 26 tests covering: source wiring, command resolution logic, fallback paths, i18n completeness (key counts + translated strings), and live endpoint error paths (missing fields, unknown session, missing file 404 with path, path traversal rejection)

CHANGELOG.md — updated

Why It Matters

Developers frequently need to inspect or continue editing files that Hermes created or modified. Previously they had to manually copy the path and open VS Code themselves. This cuts that to a single right-click.

Verification

pytest tests/test_2735_open_in_vscode.py -v
# 26 passed
pytest tests/ -v
# 26 new pass; 6 pre-existing failures unrelated to this change

Manual: right-click any file/folder in the workspace panel → Open in VS Code → file opens in VS Code.

Tested on macOS with code at /usr/local/bin/code (symlink to app bundle CLI). The shutil.which + fallback path logic handles the case where the server process inherits a minimal PATH (the root cause of the "not found" error when running via start.sh).

Risks / Follow-ups

• Windows path-mapping was implemented and covered in tests but not manually verified (no Windows test machine available); the fallback paths use standard VS Code installer locations
• The action is always visible; a future vscode.enabled: false config flag could hide it for users who prefer not to see it
• Non-English locales are translated; zh-TW uses Traditional Chinese characters

Model Used

Provider: Anthropic via GitHub Copilot
Model: github-copilot/claude-sonnet-4.6
Mode: OpenCode agent with Karpathy guidelines skill active

Closes #2735

[AlexeyDsov]

I think this should be an optional feature and not enabled by default, because not everyone uses vs code, even if it is popular.

[munim]

I think this should be an optional feature and not enabled by default, because not everyone uses vs code, even if it is popular.

@AlexeyDsov Yeah agree with you. This should a feature to turned off by default. In that case, how there' should be a documentation in place. What do you suggest?

[nesquena-hermes]

Reading the diff at api/routes.py:9521-9608 against the existing _handle_file_reveal pattern at :9460-9491 on origin/master, plus the i18n + UI wiring — overall this is the right shape and matches the existing "reveal in file manager" affordance closely. A few concrete things to look at before merge.

On the endpoint design

The safe_resolve(Path(s.workspace), body["path"]) + target.exists() guards (api/routes.py:9543-9545) match _handle_file_reveal exactly, including the explicit 404-with-path error wording. Good. The "no command found" error message is also genuinely helpful — far better than a bare FileNotFoundError.

One worry on the fallback path list:

_vscode_fallbacks = [
    "/usr/local/bin/code",
    "/Applications/Visual Studio Code.app/Contents/Resources/app/bin/code",
    "/usr/bin/code",
    "/snap/bin/code",
    os.path.join(_local_app_data, "Programs", "Microsoft VS Code", "bin", "code.cmd"),
    os.path.join(_prog_files, "Microsoft VS Code", "bin", "code.cmd"),
    os.path.join(_prog_files_x86, "Microsoft VS Code", "bin", "code.cmd"),
]

Three gaps worth filling, in order of impact:

1. No VS Code Insiders, VSCodium, or Cursor. Many Hermes users are on Cursor (Cursor ACP / Composer support landed in fix(webui): route Cursor ACP and gate reasoning effort by model #2792). Cursor's CLI is cursor, Insiders is code-insiders, VSCodium is codium. A single vscode.command: cursor override in config.yaml handles it for individuals, but the affordance "Open in VS Code" implies VS Code specifically. Either (a) keep the action narrow and explicit, or (b) generalize to "Open in editor" and probe a small ordered list. Even adding code-insiders to the fallback list would help.
2. Flatpak install location. /var/lib/flatpak/exports/bin/code and ~/.local/share/flatpak/exports/bin/code are common on Linux desktops. Not load-bearing but inexpensive to add.
3. macOS Apple-Silicon Homebrew prefix. Homebrew on M1+ installs to /opt/homebrew/bin/code. shutil.which will find it when PATH is set, but the fallback list is reached precisely when PATH is minimal (the comment at :9576 calls this out). Worth adding /opt/homebrew/bin/code.

Process semantics

subprocess.Popen([resolved_cmd, target_str]) (no shell=True, no stdout= capture) is correct — VS Code's code CLI on macOS/Linux exits immediately after handing the path off to the running instance, so no zombie. On Windows, code.cmd is a batch wrapper; subprocess.Popen invokes it via CreateProcess with the .cmd extension which is handled by Windows for cmd files. That should work but is worth a manual smoke test (which the PR body honestly flags as not done). Consider adding close_fds=True on POSIX and creationflags=subprocess.CREATE_NO_WINDOW on Windows so the launcher doesn't briefly flash a console window.

Docker path translation

The container_path_prefix / host_path_prefix block (:9558-9562) is a clean way to bridge the dockerized server case. One edge: if container_prefix matches but the translated host path doesn't actually exist (user mounted a different host dir), VS Code will silently open an empty window. Not a blocker, but the docstring could note that the server can't verify the translated path exists from inside the container.

Endpoint security

safe_resolve defends against ../ path traversal. subprocess.Popen([list_of_args]) with no shell defends against argv injection. target_str is the resolved absolute path, not user input. The only attacker-controllable bit is body["path"], which safe_resolve clamps. Looks fine.

One small additional hardening: I don't see the endpoint behind an auth gate. Most /api/* POSTs in this codebase rely on cookie-bound session ownership via get_session, which this code uses correctly via s = get_session(body["session_id"]). Good — that's the same check _handle_file_reveal relies on.

Tests

The 26-test file (tests/test_2735_open_in_vscode.py) covering source wiring, fallback path logic, i18n key counts, and the live endpoint error paths is solid for a feature of this size. Path-traversal rejection and the 404-with-path case are explicitly tested, which matches the existing patterns for _handle_file_reveal.

LGTM after considering at least the Cursor/Insiders/Homebrew-prefix additions to the fallback list, plus the Windows window-flash flag. The closed issue #2735 was specifically the maintainer's ask, so this lands cleanly when those nits are addressed.

[nesquena-hermes]

Shipped in v0.51.123 via release/stage-batch5 (#2816). 'Open in VS Code' is now in the workspace file browser context menu alongside Reveal in File Manager. The safe_resolve traversal guard + Docker host_path_prefix config are in. Closes #2735.