strIDEterm:把 Shell、AI 编码智能体与代码审查整合进工作区
jstradej/strideterm
strIDEterm 将 Shell、Claude Code、Codex、Gemini CLI、GitHub Copilot 等 AI 编码智能体、Docker 与 Git 整合进可远程访问的工作区,支持最多四个工作区并排的五种网格布局。
strIDEterm organizes your shells, AI coding agents, code reviews, Docker, and Git into workspaces you can access from anywhere — no more chaos across terminals, just focused work.
Features
- Workspaces - organize projects into separate workspaces, each with its own terminal tabs, working directory, and settings
- Tab Templates - quickly add Shell, Claude Code, Codex, Gemini CLI, GitHub Copilot, OpenCode, Dev Server, Files, and other preset tabs
- File Manager - browse, preview, and edit files with an expandable tree, resizable panels, and right-click context menu (copy, rename, delete)
- Embedded Browser - open web pages directly in a tab with URL bar and navigation controls
- Profiles - group workspaces (e.g. Work, Personal, Client projects) with a colored profile bar; each profile can be pinned to its own window for parallel use. Profiles are an organizational construct, not a security boundary — credentials, the state file, and runtime managers are shared across profiles in one install
- Workspace Grid (Split Panes) - pin up to four workspaces side by side in five layouts (columns, rows, top-split, left-split, 2×2 grid). Drag workspaces from the sidebar into a cell, swap cells, or toggle the grid with
Ctrl+Shift+G. The grid is saved per profile - Tab Split Layouts - within a single workspace, arrange terminal tabs in columns, rows, or a grid — see multiple tabs at once without switching
- Multiple Windows - open additional windows with
Ctrl+Shift+N, each pinned to one profile (a profile can be open in at most one window at a time). Window bounds and display assignment persist across restarts - Git Integration - branch info, dirty count, commit log, worktree creation, and Lazygit support
- Multi-repo Workspaces - group sibling repositories (e.g. microservices) under one workspace via
gitRoots; Git pane shows a repo switcher above the tabs, and a dedicated Bulk sub-tab runs Fetch all / Pull all (ff-only) across every repo with per-row status. Single-repo behavior is unchanged whengitRootsis empty or has a single entry. - Azure DevOps PR Review - pull request inbox grouped by repo, managed review workspaces, AI agent integration (review + fix code), push & publish workflow, and MCP bridge — see docs
- GitHub PR Review - pull request inbox, managed review workspaces with local checkout, comment and review submission (Approve / Request Changes / Comment), push & publish workflow, and MCP bridge for AI agents — see docs
- Agent Task Runner - supervised coding loop with Worker + Judge agents (Claude Code, Codex CLI, Gemini CLI, GitHub Copilot, or OpenCode for either role): runs deterministic checks between rounds, git-aware judge evaluation, periodic context refresh (shower mode), and a Dashboard UI for monitoring progress. The task brief and worker rules live in editable
TASK.md/WORKER.mdfiles — concrete verification commands belong in your brief, not auto-detected from the repo — see docs - Docker Manager - list containers, run actions, open shells, and stream logs
- SSH Support - connect to remote machines from a saved host book or ad-hoc, with built-in key manager, host key TOFU verification,
~/.ssh/configimport, SSH agent support, jump hosts, and three launch modes (built-in, systemssh, or WSL) — see docs - Remote Access - access your workspace from any device via LAN or Cloudflare tunnel with QR code; browser sessions expire after 24 hours idle or 7 days total by default and can be revoked in Settings
- Telegram Bot - forward strIDEterm alerts to a Telegram chat and reply / tap inline buttons to drive the app from your phone — start a task, pause / resume agents, capture screenshots, fetch task files, open a PR review, grab the remote-access URL via
/tunnel, all over Telegram's long-polling API (no webhook, no public tunnel) — see docs - Plugins - extend functionality with plugins (Docker Ops and System Monitor built-in)
- Finish Notifications - know when a command or agent finishes without watching the screen:
- Audio ding when focused, system notification when in background
- OSC 133 shell integration (auto-injected for bash/zsh/PowerShell) for instant detection
- Silence-based heuristics for AI agents with configurable timing
- Optional notification hooks for Claude Code, Gemini CLI, Codex CLI, and GitHub Copilot CLI, plus a native OpenCode plugin — one click in Settings enables instant idle/waiting alerts. Codex requires v0.121.0+ on Windows; Copilot requires v1.0.32+.
- Questions are told apart from idle waiting: a permission prompt, an
AskUserQuestion, an MCP elicitation dialog or a background session needing input raises a distinctquestionalert — its own icon, its own three-tone sound, a toast that does not disappear on its own, text saying what is being approved ("Bash: chmod +x deploy.sh"), and a separate Telegram filter. Plainidle_prompt(the agent stopped talking) stays the quieterwaiting - Optional auto-approve with an audit trail (Claude Code, off by default): strIDEterm can answer permission prompts for you so the agent never stops. Every decision is recorded in SQLite, shown in a searchable log in Settings, added silently to the Notification Center and optionally forwarded to Telegram — and if the record cannot be written, the approval does not happen.
AskUserQuestion,ExitPlanMode, task workspaces and any session that cannot prove it belongs to a terminal this instance spawned are never auto-approved, and the setting cannot be switched on from a remote client - Tunable per user via settings or environment variables
- Keyboard Shortcuts - navigate workspaces, tabs, windows, and the grid entirely from the keyboard — see the shortcut reference below
- Light/Dark Theme - full theme support including terminal colors and title bar
- Drag & Drop - reorder workspaces and tabs by dragging
- Mobile-Responsive Remote UI - the web client served by the remote-access server adapts to phone-width viewports: the workspace sidebar, Git pane chrome, Azure DevOps / GitHub PR inbox and review panes, and per-tab actions all collapse into popovers and full-width controls so you can drive a workspace from a phone over LAN or a Cloudflare tunnel
- Select Text by Touch - a long press in the terminal (or the ⿴ control on any touch device, or Select text in the mobile input bar's ⋯ menu) opens a snapshot of the visible screen as plain text. Select words and ranges with the phone's own handles and copy with Copy selection, Copy all, or the system Copy menu — the snapshot holds still while the PTY keeps writing and a TUI keeps repainting. Include earlier output re-takes it with up to 500 lines of scrollback
- Free where it runs, paid where it is hosted - the terminal, the workspaces, the agents, LAN remote access and the Cloudflare Quick Tunnel are free and consult no account. What a subscription pays for is the hosted control plane behind the companion phone app: the pairing, the notification and command path, push delivery and the managed relay. Signing out, letting a subscription lapse or revoking every device never limits anything local
- Account and billing, in Settings → Mobile - the section the tab leads with: the plan, the renewal date, the machines and phones on the account, and a link that opens the billing portal in your system browser. Signing in is an email address and a one-time link — there is no strIDEterm password to create, type or reset — and the link can be opened on this computer or on your phone; the last step happens on the machine being signed in. Paddle is the Merchant of Record, so invoices, card changes and cancellation live there; nothing in strIDEterm renders a payment form. Each data directory is its own installation, with its own key and its own place on the account
Screenshots
| Welcome Screen | Add Workspace | Create Workspace |
|---|---|---|
![]() |
![]() |
![]() |
| Notifications | Remote Access | Lazydocker |
|---|---|---|
![]() |
![]() |
![]() |
Installation
Download the latest release — pre-built installers are available for all major platforms:
| Platform | Format |
|---|---|
| Windows | NSIS installer (.exe) + portable |
| macOS | DMG (.dmg) — -mac-arm64 for Apple Silicon (M1/M2/M3/M4), -mac-x64 for Intel |
| Linux | AppImage (.AppImage) + Debian package (.deb) |
Nightly builds from the latest master are also published on the Releases page.
macOS — pick the right architecture: Apple Silicon Macs (M1, M2, M3, M4) need the
-mac-arm64.dmg; Intel Macs need the-mac-x64.dmg. The arm64 binary runs natively on Apple Silicon; the x64 binary runs through Rosetta 2 translation, which adds noticeable latency to the WebGL terminal renderer (laggy scroll, sluggish redraws). If you're not sure which Mac you have: Apple menu → About This Mac → "Chip" says "Apple M…" for arm64 or "Intel" for x64. To verify a running install: open Activity Monitor, findstrIDEterm, and check the Kind column —Applemeans native,Intelmeans Rosetta.
Code signing: the Windows installer is code-signed. macOS DMGs and Linux artifacts are not currently signed/notarized — on first launch macOS Gatekeeper will require System Settings → Privacy & Security → Open Anyway (or
xattr -dr com.apple.quarantine strIDEterm.app), and Linux package managers may warn about the unsigned.deb.
Quick install
The snippets below resolve the latest release tag from the GitHub API and download the matching artifact. They produce the same installers as clicking the buttons above.
Linux — AppImage (universal)
VER=$(curl -fsSL https://api.github.com/repos/jstradej/strideterm/releases/latest | grep -m1 '"tag_name":' | cut -d'"' -f4 | sed 's/^v//') curl -fL -o strIDEterm.AppImage \ "https://github.com/jstradej/strideterm/releases/latest/download/strIDEterm-${VER}.AppImage" chmod +x strIDEterm.AppImage ./strIDEterm.AppImage
AppImage requires FUSE. On Ubuntu 24.04+ install libfuse2t64, on older Debian/Ubuntu install libfuse2. To skip FUSE entirely, launch with ./strIDEterm.AppImage --appimage-extract-and-run.
Linux — Debian / Ubuntu (`.deb`)
VER=$(curl -fsSL https://api.github.com/repos/jstradej/strideterm/releases/latest | grep -m1 '"tag_name":' | cut -d'"' -f4 | sed 's/^v//') curl -fL -o /tmp/strideterm.deb \ "https://github.com/jstradej/strideterm/releases/latest/download/strideterm_${VER}_amd64.deb" sudo apt install /tmp/strideterm.deb strideterm
macOS — Apple Silicon (arm64) — M1, M2, M3, M4
VER=$(curl -fsSL https://api.github.com/repos/jstradej/strideterm/releases/latest | grep -m1 '"tag_name":' | cut -d'"' -f4 | sed 's/^v//') curl -fL -o strIDEterm.dmg \ "https://github.com/jstradej/strideterm/releases/latest/download/strIDEterm-${VER}-mac-arm64.dmg" open strIDEterm.dmg
macOS — Intel (x64) — Intel Macs only; do NOT use on Apple Silicon (Rosetta makes rendering slow and is being phased out by Apple)
VER=$(curl -fsSL https://api.github.com/repos/jstradej/strideterm/releases/latest | grep -m1 '"tag_name":' | cut -d'"' -f4 | sed 's/^v//') curl -fL -o strIDEterm.dmg \ "https://github.com/jstradej/strideterm/releases/latest/download/strIDEterm-${VER}-mac-x64.dmg" open strIDEterm.dmg
Windows — installer (PowerShell)
$ver = (Invoke-RestMethod https://api.github.com/repos/jstradej/strideterm/releases/latest).tag_name.TrimStart('v') Invoke-WebRequest -Uri "https://github.com/jstradej/strideterm/releases/latest/download/strIDEterm-Setup-$ver.exe" -OutFile strIDEterm-Setup.exe Start-Process .\strIDEterm-Setup.exe
Windows — portable (PowerShell)
$ver = (Invoke-RestMethod https://api.github.com/repos/jstradej/strideterm/releases/latest).tag_name.TrimStart('v') Invoke-WebRequest -Uri "https://github.com/jstradej/strideterm/releases/latest/download/strIDEterm-$ver-win-x64.exe" -OutFile strIDEterm.exe .\strIDEterm.exe
Building from source is for contributors — see the Development Guide.
Configuration
All state is stored in ~/.strideterm/:
strideterm-state.json- workspaces, profiles, settings, tab templateslogs/- structured application logs (winston, configurable level)plugins/- user plugins directory
Settings are accessible via the gear icon in the sidebar (General, Tab Templates, Git, SSH, Telegram, About). Notification timing and agent-hook setup live inside the General tab. strIDEterm checks for updates on startup and shows available releases in the About tab.
Multiple Instances (Custom Data Directory)
You can run multiple strIDEterm instances side by side (e.g. a packaged EXE and a dev build) by giving each its own data directory:
# Packaged app strideterm.exe --data-dir C:\Users\me\.strideterm-dev # Dev mode STRIDETERM_DATA_DIR=~/.strideterm-dev npm run dev:electron # Or pass it directly to Electron npx electron . --data-dir ~/.strideterm-dev
Each data directory gets its own state file, logs, credentials, and single-instance lock. The window title shows the directory name as a suffix so you can tell instances apart. --data-dir takes precedence over the STRIDETERM_DATA_DIR environment variable.
Terminal Renderer (WebGL)
The terminal pane uses a WebGL renderer by default — it draws the whole viewport in a single GPU call, which keeps scrolling smooth under heavy TUI traffic (Claude Code, htop, tig, lazygit, etc.). On startup strIDEterm probes WebGL2 support: it creates a test context with failIfMajorPerformanceCaveat, blacklists known software rasterizers (SwiftShader, llvmpipe, Microsoft Basic Render), and compiles a trivial shader. If any step fails, the terminal silently falls back to the built-in DOM renderer. Every probe result and load attempt is written to logs/strideterm.log under the [renderer] label so you can see why a fallback happened.
If WebGL renders incorrectly on your device (giant glyphs, blank canvas, or visual glitches — occasionally observed on older Macs and certain Intel iGPUs) you can force the DOM renderer:
# Per-launch (CLI flag — wins over the env var) strideterm --no-webgl # Globally (environment variable) STRIDETERM_DISABLE_WEBGL=1 strideterm
--no-webgl is the recommended fix when one desktop installation is affected — add it to your shortcut, .desktop file, or launch command. The env var is convenient when you want the same behavior across every shell and shortcut on a host. Remote web/mobile clients also try the WebGL renderer now; unsupported implementations stay on the DOM renderer, and a lost context is disposed and retried with a bounded fallback policy.
Remote Access
strIDEterm can expose the workspace over HTTP/WebSocket to another device. Remote access is off by default — turn it on in Settings, or set STRIDETERM_REMOTE_ENABLED=true before launch, so the server actually starts listening.
# Enable remote access for this launch (LAN-accessible) STRIDETERM_REMOTE_ENABLED=true npm start # Desktop-only (bind to loopback so nothing on the LAN can reach the port) STRIDETERM_REMOTE_ENABLED=true STRIDETERM_REMOTE_HOST=127.0.0.1 npm start
Once enabled, the server binds to 0.0.0.0:43123 by default. From another device: http://<your-lan-ip>:43123/?token=<token>
Security: treat the remote token like a password. Use LAN mode only on trusted networks. Even with a valid token, remote clients cannot toggle Cloudflare auto-tunnel, repoint the cloudflared binary, change the bind host/port, rotate the token, edit customPublicUrl, or flip externalPathOpener — those settings are local-IPC only. Every settings update and HTTP/WS request from a remote client is filtered through a server-side blocklist (a fixed set of dangerous keys is dropped) and validated against shared Zod schemas before reaching the runtime.
Telegram Bot
strIDEterm can forward workspace alerts to a Telegram chat and let you reply to act on them — start a task, pause / resume agents, capture screenshots, fetch task files, open a PR review. The whole feature uses Telegram's getUpdates long-polling API, so the strIDEterm machine only needs outbound HTTPS to api.telegram.org (no public webhook, no Cloudflare tunnel).
- Talk to @BotFather in Telegram →
/newbot→ copy the token - Send
/startto your new bot from your account - Open Settings → Telegram, paste the token, click Detect to find the chat, save
The Telegram tab in the notification panel shows each connection's status, poll interval, and forward filter at a glance, with a one-click Configure shortcut. From the bot, /menu is the recommended entry point on mobile — it gives one-tap access to status, new task, screenshot, workspaces, and help.
The bot token is stored encrypted via the OS keychain, the chat-ID allowlist is enforced on every incoming update, and the Get-file flow refuses paths that resolve outside the task workspace's cwd. See Telegram docs for the full feature reference, security model, and technical overview.
Agent Task Runner
strIDEterm can run a supervised coding loop where a Worker agent implements your task while a Judge agent independently verifies the results. Worker and Judge can each be Claude Code, Codex CLI, Gemini CLI, GitHub Copilot, or OpenCode — mix and match (e.g. Claude worker + Copilot judge). Between rounds, the runner uses git diffs to give the judge full context of what changed.
- Create a task workspace from the sidebar context menu
- Pick the Worker and Judge providers and models (or use a custom CLI command)
- Describe what you want built. The runner pre-fills a generic verification block — concrete commands belong in your brief
- Press Start — the Worker codes, the Judge reviews, repeat until done
Key features: editable TASK.md brief and WORKER.md rules, TODO/WORK_LOCK file protocol, periodic context refresh (shower mode) for long tasks, and a Dashboard tab showing round-by-round progress with judge feedback.
Requires at least one of Claude Code CLI (claude), Codex CLI (codex), Gemini CLI (gemini), GitHub Copilot CLI (copilot), or OpenCode (opencode) on your PATH. See Agent Task Runner docs for full details.
Agent Notification Hooks
strIDEterm integrates with each supported agent CLI's hook system so you get instant alerts when an agent finishes a turn or needs input — no polling, no silence timers. One-click setup per provider in Settings → General (under Agent notification hook):
| Provider | Config location | Events registered | Notes |
|---|---|---|---|
| Claude Code | ~/.claude/settings.json |
Notification, Stop, SubagentStop, UserPromptSubmit, PreToolUse, PermissionRequest | Widest event coverage. PermissionRequest lets alerts name the tool being approved, and powers the optional auto-approve below |
| Gemini CLI | ~/.gemini/settings.json |
AfterAgent, Notification, BeforeAgent | Event names auto-mapped to Claude aliases |
| Codex CLI | ~/.codex/hooks.json + [features] hooks = true in ~/.codex/config.toml |
Stop, UserPromptSubmit | Requires Codex CLI 0.121.0+ on Windows (PR #17268); first run may require approving strIDEterm hooks via /hooks |
| GitHub Copilot | ~/.copilot/config.json (top-level hooks key) |
sessionEnd, userPromptSubmitted | Requires Copilot CLI 1.0.32+. Respects COPILOT_HOME env var override |
| OpenCode | ~/.config/opencode/plugins/strideterm-notify.js (same path on Windows) |
session.idle, chat.message | Native OpenCode plugin, not a hook entry — OpenCode's config has no hooks key and refuses to start if one is present. Honors XDG_CONFIG_HOME |
The four hook-based providers share a single notification script (~/.strideterm/hooks/notify.mjs) that posts events to a local HTTP endpoint embedded in strIDEterm. The script is written automatically on startup, so you never need to edit it by hand. OpenCode reaches the same endpoint from inside its own process — its plugin reads the STRIDETERM_NOTIFY_URL that strIDEterm injects into every terminal session, so an opencode started outside strIDEterm sends nothing. Settings also exposes a Test hook button that runs an end-to-end probe and reports delivery latency.
Without hooks the Task Runner falls back to a silence-based heuristic (8 s default) for all five providers. OSC 133 shell integration only fires when a shell returns to its prompt, so for interactive agent sessions (which never return to a prompt between turns) it doesn't help — hooks carry the primary signal. Hooks are optional but strongly recommended for long Judge reasoning passes where silence timers add up. Codex may also show "hooks need review" after configuration; open /hooks in Codex and approve the two strIDEterm entries once.
Auto-approve permission prompts (Claude Code)
Settings → General → Notifications → Auto-approve permission prompts. Off by default, and disabled until the agent notification hook is on and the Claude Code hooks are configured.
When enabled, strIDEterm answers Claude Code's PermissionRequest hook with allow: the prompt does not appear in the terminal and the agent keeps working. This is equivalent to running the agent without permission prompts, so treat it as such — it is a bypass, not a filter. What keeps it accountable:
- Every decision is recorded in
approval-audit-log.dbin the data directory (30-day retention), listed in the Approvals tab of the notification panel — one row per decision, newest first, grouped by day and searchable by workspace, panel, tool or command; click a row for the full command, the reason, and the Claude session id that finds it in the agent's own transcript. The tab is there whenever auto-approve is armed or the profile has approvals on record, so disarming never hides what was already approved. Each approval is also added to the Notification Center as a silent entry. That entry arrives as a live event, so the history is rebuilt from the log whenever a window could have missed one — at start-up, when you switch back to a profile, and after a remote client reconnects — continuing from the last entry it filled in, and in further passes when a lot happened while you were away, so a long absence is caught up completely rather than only its most recent page — in the right order, with the newest approvals kept when the history is full, and retried on its own if a catch-up fails. An approval too old to fit alongside them changes nothing on screen — it never marks a thread you already cleared as unread again. If the record cannot be written, the approval is refused and the prompt is shown instead. Rows readdecision-issued, not "approved": strIDEterm knows it handed a decision to the hook's stdout, and nothing in the flow reports back whether Claude Code acted on it. - The panel has to prove it is yours. Hooks are routed by project directory, which proves nothing on its own — a
claudeyou started in a plain terminal in the same repository reaches strIDEterm exactly like the real one does. Each terminal strIDEterm spawns therefore carries an ownership token (STRIDETERM_SESSION_TOKEN) that the hook echoes back; a request without the right token for the session it names is never auto-approved. If your setup does not pass the terminal's environment through to hook processes, nothing is auto-approved and the prompt is shown — which is the same outcome as having no hook at all. - One decision, one instance. The hook runs a two-phase handshake: every reachable strIDEterm is asked whether it would answer, and only when exactly one offers is that one told to commit. Nothing is recorded, notified or forwarded before that point, so two instances over the same repository leave no "approved" trail behind them — neither answers, and the prompt appears. The commit is not a rubber stamp on the offer either: the setting, the never-list, the ownership token and the active turn are all re-checked against the state as it is then, so unticking the box, ending the turn or closing the panel voids an offer already made — a repeat of a commit already answered included.
- One request, one decision. Each run of the hook script carries its own random delivery id, and both legs of the handshake — the offer and the commit that answers it — are checked against the same panel, the same delivery, the same tool and the same arguments; a decision is only ever replayed on that same identity, and only after every check above has passed again. Claude's
PermissionRequestinput has nothing that identifies the individual request — there is notool_use_id, andprompt_idnames the whole user turn — so nothing else is treated as an identity: two tools in one turn are two questions, answered (or refused) one at a time. - Never auto-approved:
AskUserQuestionandExitPlanMode(both need a real answer, not a rubber stamp), any panel in a task-runner workspace, and any session outside an active turn. - One prompt is out of reach. A tool call blocked by Claude Code's sandbox for network access raises no
PermissionRequest— Claude asks about it through a plain notification, which carries no decision back. That prompt still appears and is still yours to answer; strIDEterm names the tool in the alert and nothing more. - Your own rules still win. Claude Code evaluates deny and ask rules from
/permissionsbefore the hook, so the hook only ever sees requests Claude was going to ask you about. - You can delete rows, from the desktop. Individual rows, or the whole trail for a profile, from the Approvals tab. There is no remote route for it: reading the record of an unattended bypass from a phone is fine, erasing it is not — the same reasoning that keeps a remote client from arming it in the first place. A deletion leaves no rows behind but does leave a line in
strideterm.logsaying how many went and when. Retention clears the rest after 30 days. - Remote clients cannot enable it.
POST /api/settings/updatedrops the field; arming an unattended bypass has to happen at the machine that will execute the result. Turning the agent notification hook off also disarms auto-approve, so a remote client turning the hook back on cannot silently re-arm the bypass. Reading the log over remote (GET /api/approvals/audit-log) is allowed, scoped to the profile the calling session is bound to — a caller presenting the master token with no bound session reads the whole installation's trail, which that token already grants in full. - If you already run your own
PermissionRequesthook, don't run both: hooks for one event execute in parallel and the docs don't define which decision wins. - Requires Claude Code 2.0.45+ (when the
PermissionRequesthook was added), and nothing beyond it: the flow uses only fields that hook has carried since then.prompt_id(2.1.196+) andagent_idsharpen the match between a request and the notification that follows it, and are simply absent on an older CLI; when the notification names one and no parked request agrees with it, the alert keeps Claude's own wording rather than describing a tool it cannot prove is the right one. On a CLI older than 2.0.45 the hook never fires at all: alerts fall back to Claude's own message text and nothing is auto-approved. Thequestionalert kind itself needs no minimum version, exceptagent_needs_input, which Claude Code only sends from 2.1.198.
Copilot note: if the user has disableAllHooks: true set in ~/.copilot/config.json (Copilot's global kill-switch), Settings shows a distinct "Configured — hooks disabled" badge so you know installed entries won't fire until you clear the flag.
Keyboard Shortcuts
| Shortcut | Action |
|---|---|
Ctrl+1 … Ctrl+9 |
Switch to the Nth workspace in the current profile |
Ctrl+PgUp / Ctrl+PgDown |
Cycle through tabs in the active workspace |
Ctrl+Shift+PgUp / PgDown |
Cycle through workspaces in the current profile |
Ctrl+N |
Create a new workspace |
Ctrl+W |
Cascading close: active tab → workspace (navigate to next) → window |
Ctrl+R |
Restart the active terminal session |
Ctrl+F |
Open the per-pane search bar (find text in the terminal scrollback) |
Ctrl+Shift+N |
Open a new window (desktop) — picks a profile to pin. In the remote web UI: focus the notification dock |
Ctrl+Shift+W |
Close the current window (multi-window only) |
Ctrl+Shift+G |
Toggle the workspace grid (split panes across workspaces) |
Ctrl+\ |
Cycle through grid layouts (cols → rows → grid → top-split → left-split) |
Alt+1 … Alt+4 |
Focus the Nth cell of the workspace grid |
Alt+Shift+1 … Alt+Shift+4 |
Open the workspace picker for the Nth grid cell |
On macOS, substitute Cmd for Ctrl. Shortcuts inside the terminal pane are intercepted before xterm consumes them so they always work regardless of which TUI is focused.
Plugins
Built-in plugins (under plugins/):
- Azure DevOps — workspace template for the Azure DevOps PR inbox
- GitHub — workspace template for the GitHub PR inbox
- Docker Ops — container management workspace
- System Monitor — system dashboard
User plugins: ~/.strideterm/plugins/
See Plugin Development Guide for details.
Development
Building from source, running tests, and the project architecture are documented separately so this README stays focused on using the app:
- Development Guide — requirements, dev startup, build & test commands, packaging notes
- Architecture — runtime/adapter/renderer breakdown and key patterns
- Contributing — commit and PR conventions
License
来源:GitHub · github.com






