Terminal interaction is unusable for many common tasks (copy/paste, link handling, file delivery) — proposal to fix

Terminal interaction is unusable for many common tasks (copy/paste, link handling, file delivery) — proposal to fix

Summary

When jcode is accessed through a standard terminal emulator (e.g. MobaXterm on Windows, plain SSH, or a Docker exec session), the day-to-day workflow degrades sharply. Operations that should be one-click become painful or impossible, which in turn pushes the assistant into escalating workarounds that further frustrate the user.

This issue collects concrete failure modes observed in a real session, with the goal of turning a one-off complaint into actionable UX fixes.

Environment

• jcode v0.61.0 (commit c5009da0).
• Host: aarch64 NAS-style machine, 1.5 GiB RAM.
• Client: Windows + MobaXterm over SSH to a remote container, no graphical access.

Observed failure modes

1. Copy and paste are unreliable or effectively unusable.

The chat transcript is rendered as terminal text. Selecting and copying URLs longer than ~30 characters (e.g. ~200-character Mediamarkt product URLs) becomes painful: selection drops characters, word-break selection is triggered, or the operation simply requires gestures that are not discoverable. Users end up typing long URLs by hand instead of copying them.

2. Hyperlinks in chat output are not actionable.

There is no clickable-link behaviour in the terminal case, and OSC 8 hyperlinks are either not emitted or not honored by the terminals that matter (MobaXterm partially supports them; many SSH clients do not). The user reads the URL but cannot open it.

3. File-based workarounds fall back to the same broken primitive.

Side panels, cat of files the assistant writes, and "download from SFTP browser" all eventually depend on copy/paste — of long file names, paths, or host:port combinations. When copy is broken, every one of these "fixes" inherits the original problem.

4. Long URLs silently downgrade answer quality.

When canonical links cannot be transferred, the assistant is forced to give only short hand-typeable identifiers instead of the actual product URL. In one session the answer went from "exact product URL" down to "type 'Zenbook UM3406KA' into Mediamarkt search" — a measurable quality regression masquerading as a fallback.

5. The assistant over-engineers cascades as friction increases.

Once copy/paste breaks, the assistant falls through a sequence of increasingly elaborate workarounds: SOCKS proxies, SSH tunnels, an nc-based HTTP server on a remote port, side panels, short-URL services (which are themselves unreachable from the same environment), and finally a Google search fallback. Each new suggestion costs minutes of setup. The user's reaction after several rounds was blunt: "it makes the tool unusable".

6. There is no "low text mobility" channel.

When copy is broken, the assistant has no reliable way to detect this and no canonical low-bandwidth output format. Instead, the constraint surfaces only after the user complains repeatedly.

Proposed changes

These are suggestions for discussion, not pre-committed work.

• Detect or let users declare a low-text-mobility mode. When active, the assistant prefers: short hand-typeable identifiers, QR-code images, self-contained HTML in the SFTP path that the user double-clicks, and OSC 8 hyperlinks on terminals that support them.
• Out-of-band delivery. A per-session optional channel (Telegram, email, push, SMS) so users on locked-down terminals receive the assistant's output without copy/paste.
• OSC 8 hyperlinks in TUI output. Cheap to emit, supported by most modern terminals, MobaXterm supports them partially — a meaningful low-effort win.
• "Copy last assistant message" keybinding. Emit OSC 52 (\e]52;c;<base64>\a) on terminals that support it, fall back to xclip / pbcopy where available. Single keystroke, large benefit.
• Document the official escape hatches. A short page in the docs explaining how to retrieve long strings from the assistant when copy is broken: download last message from the web UI, double-click a one-shot HTML in the SFTP browser, request a QR code, paste into a configured Telegram mirror, or as a last resort, manually type a short identifier.

Reproduction

1. Install jcode on any aarch64 / Linux host.
2. Connect with MobaXterm over SSH.
3. Ask the assistant for a small piece of information requiring a long URL (for example "compare a specific laptop on Mediamarkt and PcComponentes").
4. Try to open the URLs from the chat.

The expected behaviour is "click the link and it opens in the browser". The actual behaviour is the cascade described above.

Direct quotes from the user

• "I can't cut and paste from this terminal."
• "The history deletes, I can't copy, what a pain."
• "It doesn't copy, surely many people complain about this, it makes the tool unusable."
• "You're telling me that to copy a piece of text I see on screen I have to do a tour de force, you're crazy."
• "You can't even copy, you'd have to jump through hoops."

The convergence of these complaints across a single short session suggests this is structural, not isolated.

Start by examining jcode's terminal and TUI interaction entry points, then reproduce the copy/paste and link-handling problems over SSH with MobaXterm as described. Before implementation, narrow the proposal to an agreed behavior such as OSC 8 links, OSC 52 copying, or a documented fallback; done should be demonstrated by the corresponding reproduction working reliably.