Prepare and inspect plans for opening interactive commands in a visible WezTerm window while keeping the executable and arguments separate. Check terminal availability, preview launches as JSON, and use fallback or recovery modes when needed.
Open an executable and its argument array in a visible terminal window through a reusable, shell-free launch plan with dry-run, JSON, capability detection, detached fallback, and standalone recovery modes. Use when Codex needs to open an interactive CLI, SSH session, local development process, sandbox, or other argv-based command in a new host terminal; diagnose whether a supported terminal is available; or provide an actionable plan when the requested terminal is unsupported.
Review the instructions the agent will receive before you install.
Use scripts/open-terminal.js to preserve an executable and every argument as
separate process entries. Never interpolate a shell command string. Keep every
spawn on shell: false. Default to a non-launching plan. Use --launch only
after the user explicitly requests a real window and the argv has been reviewed.
The launched process inherits the full environment of the calling process,
including secret-bearing variables. The launcher does not filter the
environment. Run it from a shell whose environment is safe to expose to the
target command.
Pass launcher options before --, then pass exactly one executable followed by
its argument array:
node skills/terminal-opener/scripts/open-terminal.js \
--launch \
--cwd /absolute/host/path \
-- ssh -t example.test command-with-arguments
Run normal mode first. Let WezTerm try its mux with a new window, then let the
launcher fall back to a detached wezterm start process if the mux is not
available. When fallback is used, read muxFailure from JSON output (or the
human-readable failure line) to diagnose why the mux path failed.
Add --recover or --standalone when user configuration or mux state may
interfere with the requested command. Start a detached WezTerm process with:
--skip-config start --always-new-process
Expect recovery mode to skip all user terminal configuration intentionally.
Omit --launch (or add --dry-run) and add --json to inspect the exact
executable, argv, working directory, terminal adapter, primary launch, and
fallback without opening a window. Treat the JSON plan as the composition
boundary for callers.
Run --detect --json without a command to probe terminal availability. Follow
the returned action when the adapter is missing or unsupported. Use WezTerm
for the current adapter; treat other requested terminals as unsupported plans,
not as commands to execute.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Design and audit interfaces for Web, iOS, and Android using WCAG 2.2 accessibility guidance. Check screen-reader labels, keyboard navigation, contrast, and control sizes to identify barriers and guide implementation for people using assistive technology.
Investigate unreliable AI agents across 12 layers, including instructions, memory, tool execution, and display. Use code and logs to trace failures, rank findings by severity, and produce an ordered repair plan that prioritizes code changes.
Compare coding agents on tasks from your own codebase. Define success checks, run agents in separate Git working directories, and report pass rates, available API costs, completion time, and consistency across repeated trials.
Design and refine an AI agent’s available actions, tool inputs, and result formats. Define recovery steps for errors, manage the information kept in context, and evaluate changes through completion rates, retries, and cost per successful task.
Diagnose AI agent runs that fail repeatedly, loop through tools, or lose track of the task. Capture errors and environment details, test a focused recovery action, and produce a report explaining the evidence and outcome.
Diagnose failed AI agent runs by capturing errors, checking likely causes, and choosing small, reversible recovery actions. The workflow produces a structured report of the failure, recovery steps, and evidence, helping explain repeated retries or stalled progress.