[Enhancement] In-terminal jumps to out-of-project file

[earthpyy]

Currently, inside terminal Termic allows us to CMD+Click to navigate into a single file (or external link). It would be great if it can also navigate to any other paths which located outside the active project as well. Detection: absolute path or not.

In addition, adding the setting which allow user to select where they want the file to be opened between in-app editor and default app (external) would also be helpful.

Questions

1. Should in-app editor opens any file outside the active project?
2. Should we handle the relative path which also resolves to paths outside of the project?
3. Is that setting necessary?
4. Any other concerns

[simion]

Partly shipped in fa73a08.

What landed

Absolute paths are now resolved rather than suffix-matched. The token keeps its / or ~/ prefix, and absolute paths take their own branch: they are mapped against the task's roots (the worktree, plus each composition member's own repo). Two things this fixes:

• Absolute paths pointing inside the task never worked either. /Users/me/proj/src/a.ts arrived at the resolver as a relative Users/me/proj/src/a.ts (the leading slash fell outside the match) and matched nothing, so it dead-ended on "No matches" even though the file was right there. That is likely a good share of what you were hitting.
• A short absolute path could open the wrong file. ~/notes/todo.md became notes/todo.md and suffix-matched an unrelated in-task docs/notes/todo.md. Absolute paths no longer fall back to suffix matching at all: landing outside every root is a real answer, not a hint to go hunting.

A path that resolves outside the task now opens the existing path menu with the resolved absolute path shown, offering Reveal in Finder, Open in default app, and Copy path.

On your Q3 (is the setting necessary)

Not so far. Rather than a preference chosen in advance, the choice is offered in the moment, which also means the destination is visible before anything runs. That matters here specifically: these strings come from agent output, open(1) executes some file types (.command, .app, .pkg), and the underline makes an arbitrary path look like a legitimate link. Showing the resolved path before any action is reachable is the mitigation, and Reveal (which dispatches to no handler) is listed first so it sits under initial focus. If a real preference turns out to be wanted on top of that, it is easy to add later.

On your Q1 (should the in-app editor open files outside the project)

Not by opening them the way in-project files open. EditTab.path is task-relative across save, the file tree, blame, review comments and the diff/git panels, and the Rust side rejects absolute paths at the boundary by design.

A read-only tab for out-of-project text files is the right answer and is worth doing as a follow-up. There is already a close precedent in ScratchTab (#244): a file living outside the worktree, read through its own IPC, with every task-scoped feature already branching to opt out. The gate should be content, not the extension: the existing read already caps size and rejects non-UTF-8, so binaries and huge files bounce on their own. Keeping it separate because it adds the first uncontained file read callable from the webview, which deserves its own review.

On your Q2 (relative paths resolving outside)

Not addressed, and not cheap. Resolving ../../other/repo/file.ts correctly needs the shell's live cwd, which termic does not track (no OSC 7 handler; the only cwd known is the one at spawn). Resolving against the task root would be a guess that breaks the moment you cd. Worth doing as its own change, since cwd tracking has independent value.

Also worth knowing: /etc/hosts still will not underline. Detection requires a file extension, which is what keeps prose with slashes ("and/or", "TCP/IP") from lighting up.

[simion]

Follow-up shipped in 8c8168d: out-of-task text files now open in a read-only editor tab, which answers Q1 properly.

Handing a .json to the OS launcher was never a good answer for a text file, so the OS actions are now the fallback rather than the destination. What is text is decided by attempting the read, not by the extension: .ts is TypeScript and MPEG transport stream, .txt and dotfiles carry no grammar at all, and a 2 GB .json is still .json. Anything the read refuses (binary, oversized, a directory) falls through to the path menu with Reveal / Open in default app / Copy path.

It is a distinct ExternalTab type rather than a flag on EditTab, for the same reason ScratchTab (#244) is one: EditTab.path is task-relative and load-bearing in saving, inline blame, review comments, the changed-on-disk watcher, locate-in-tree and the breadcrumb. A separate type makes each of those a compiler error to answer instead of a runtime surprise.

Read-only is the containment story rather than a UI nicety. The backing read is the only one in the app not bounded by a task root, so there is deliberately no write to pair with it: task_file_write keeps its containment check, the buffer is EditorState.readOnly with ⌘S stubbed, the read is capped at 2 MB and requires UTF-8, and the pinned CSP leaves nowhere to send a result. Written up under "Known gap" in docs/sandbox.md.

Rendering is source view only, never the markdown / SVG / preview shells: those resolve sibling assets and links against the task root, which an out-of-task file has no relationship to, so they would show broken images and links that go nowhere.

Leaving this issue open for Q2 (relative paths resolving outside the task), which still needs shell cwd tracking that termic does not have.

[simion]

Closing this as done. Shipped across fa73a08 and 8c8168d, and it will go out in the next release.

Where it landed, against your original questions:

1. Should the in-app editor open files outside the project? Yes, read-only. Out-of-task text files open in a read-only tab; anything the read refuses (binary, oversized, a directory) falls through to a menu offering Reveal in Finder, Open in default app, and Copy path.
2. Relative paths resolving outside the project? Deliberately not doing this. Resolving ../../other/repo/file.ts correctly needs the shell's live cwd, which termic does not track (the only cwd it knows is the one at spawn), so resolving against the task root would be a guess that breaks the moment you cd. Not worth the prerequisite work for the payoff.
3. Is the setting necessary? No setting. The choice is offered in the moment instead, which also means the destination is visible before anything runs.
4. Other concerns: absolute paths pointing inside the task never worked either, and a short one like ~/notes/todo.md could suffix-match and silently open an unrelated in-task file. Both fixed. Windows paths and /etc/hosts style extension-less paths remain out of scope.

Thanks for the report, and for the framing: the questions list is most of why this ended up scoped the way it did.

[simion]

Shipped in v1.0.0, out today. Cmd+click resolves absolute paths, and a file outside the task opens in a read-only tab. Relative paths pointing outside the project are still not resolved: that needs cwd tracking we do not have yet.

[earthpyy]

Shipped in v1.0.0, out today. Cmd+click resolves absolute paths, and a file outside the task opens in a read-only tab. Relative paths pointing outside the project are still not resolved: that needs cwd tracking we do not have yet.

Nice one! Thanks, @simion.