agentmods.dev

wezterm-runtime-sync

wezterm-runtime-sync is a skill for Claude Code, Codex from yunsii/wezdeck. It costs 58 tokens per session (1,024 once invoked), scanned A, original, MIT.

A tool for synchronizing WezTerm runtime files, where WezTerm is a terminal application, from a repository to a selected local installation. It can test changes in an isolated canary copy before publishing them.

In plain words
What is it for?
Publishing updated WezTerm configuration, discovering possible local targets, testing a runtime sync, and promoting a verified canary copy to the live environment.
Why use it?
It reduces the risk of changing the live terminal configuration with an untested version. A cached target can be reused, and the live setup remains untouched if the health check fails.

Skill for Claude CodeCodex

5 7d ago A scan 58 tokens original MIT
View the source file yunsii/wezdeck
Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/yunsii/wezdeck/wezterm-runtime-sync
Any agent
npx skills add yunsii/wezdeck --skill wezterm-runtime-sync
Clone the repo
git clone --depth 1 https://github.com/yunsii/wezdeck

Made for: Claude Code, Codex.

Per session 58 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,024 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00058 $0.01024
Opus 5 $0.00029 $0.00512
Sonnet 5 $0.00012 $0.00205
Haiku 4.5 $0.00006 $0.00102

Measured 3d ago against content hash bc225bcaca73, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

wezterm-runtime-sync scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.

The scan reads SKILL.md. This mod also ships 5 executable files (scripts/sync-helper-windows-lib.sh, scripts/sync-prompt-lib.sh, scripts/sync-runtime.sh, …), listed below but not scanned — reading those needs a real analyzer, not pattern matching.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

skills/wezterm-runtime-sync/SKILL.md · 63 lines

How it starts

The opening of the file, as written. The whole thing — 63 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Wezterm Runtime Sync

Use this skill when the task is to sync runtime files. Reuse a valid cached target when available; otherwise confirm the target home before writing anything.

The scripts under skills/wezterm-runtime-sync/scripts/ are the source of truth for sync prompting, target discovery, and prompt-format regression checks.

Workflow

  1. Run from the repository root, or set WEZDECK_REPO=/absolute/path/to/repo (legacy WEZTERM_CONFIG_REPO still accepted) before invoking the skill scripts.
  2. Default sync stages a canary tree, auto-launches an isolated WezTerm probe, and promotes to live only if healthy.stamp appears (otherwise live is untouched and sync exits 1). Skip probe with WEZTERM_SYNC_SKIP_CANARY_AUTO=1. Use --live to publish straight to the running GUI. Details: docs/daily-workflow.md.
  3. If repo-root .sync-target or WEZTERM_SYNC_TARGET already points at an existing directory, run skills/wezterm-runtime-sync/scripts/sync-runtime.sh with no extra arguments.
  4. If there is no valid cached target, run skills/wezterm-runtime-sync/scripts/sync-runtime.sh --list-targets to print candidate user home directories.
  5. Present the candidates to the user and ask which path should be used. Accept either one of the listed paths or another absolute path the user explicitly provides.
  6. After the user confirms a target, run skills/wezterm-runtime-sync/scripts/sync-runtime.sh --target-home /absolute/path.
  7. Summarize the sync result and mention the chosen target path.

Rules

  • Do not ask the user to type into the script's interactive prompt.
  • If a valid cached target exists and the user did not ask to change it, sync immediately with no extra confirmation step.
  • If the cache is missing, invalid, or the user wants to change targets, use the explicit list-and-confirm flow above.
  • Prefer --target-home over WEZTERM_SYNC_TARGET when the user has explicitly confirmed a path, because --target-home also refreshes .sync-target.
  • If the requested target is outside the writable sandbox and the sync command fails with a filesystem permission error, rerun it with escalated permissions.
  • If --list-targets prints no directories, report that clearly instead of guessing a target.
  • If the user names a path directly, validate that it is absolute and exists before running the sync.
  • Treat repo-root .sync-target as the cache for the chosen runtime home.
  • Remember that gitignored files under wezterm-x/local/ are still copied because sync reads the repository working tree, not just tracked files.
  • Sync also copies config/worktree-task.env to <runtime_dir>/repo-worktree-task.env so the Windows-side wezterm.exe can read it (io.open on a /home/... WSL path returns nil from Windows). wezterm-x/lua/constants.lua reads that local copy first; without it, the <base>_resume profile defined only in the env file is missing on the Windows leg and workspace open silently falls back to the bare profile.
  • Sync runs scripts/runtime/render-workspace-agent-map.sh (requires lua5.4) to regenerate wezterm-x/local/workspace-agent-map.tsv from workspaces.lua so shell launch paths honor per-item launcher overrides. See docs/workspaces.md#per-repo-agent-cli.
  • The lua-precheck step (between publish-runtime and helper-install) dofile-loads the synced lua/constants.lua under a mocked wezterm and asserts default_resume_profile ≠ default_profile plus a --continue / resume literal in the resume command. Requires lua5.4 (or lua5.3/lua); skips with a warning when none is installed.

Read the full file on GitHub · 63 lines

Files

What ships with it

7 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 3d ago First seen · 63 lines · 58 tokens per session scan A bc225bcaca73

Subscribe to this mod's changes

wezterm-runtime-sync is a skill published in the GitHub repository yunsii/wezdeck (5 stars, last pushed 7d ago), licensed MIT. It adds 58 tokens to every session and 1,024 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

DevOps and cloudagent-orchestrationai-agentsclaude-codecodexdeveloper-toolsgit-worktree
Related

Other skills, from other repositories

workflow

Create, run, monitor, cancel, or resume deterministic JavaScript workflows that orchestrate multiple Codex, Claude, Cursor, or Kimi agents. Use for parallel investigation or review, staged agent pipelines, resumable long-running work, or when the user explicitly asks for a workflow, orchestration, fan-out, or several…

xxxoooxoxo/wiff · 70 tokens

orchestrate

Use only when the user explicitly types /orchestrate:orchestrate to decompose a large task, spawn a tree of parallel worker/subplanner/verifier subagents, and collect structured handoffs. Do not invoke autonomously.

odysseus0/claude-orchestrate · 54 tokens

launch

Launch and automate VS Code (Code OSS) using agent-browser via Chrome DevTools Protocol. Use when you need to interact with the VS Code UI, automate the chat panel, test UI features, or take screenshots of VS Code. Triggers include 'automate VS Code', 'interact with chat', 'test the UI', 'take a screenshot', 'launch…

workstream-labs/workstreams · 80 tokens

accessibility

Primary accessibility skill for VS Code. REQUIRED for new feature and contribution work, and also applies to updates of existing UI. Covers accessibility help dialogs, accessible views, verbosity settings, signals, ARIA announcements, keyboard navigation, and ARIA labels/roles.

workstream-labs/workstreams · 54 tokens

sessions

Agent Sessions window architecture — covers the sessions-first app, layering, folder structure, chat widget, menus, contributions, entry points, and development guidelines. Use when implementing features or fixing issues in the Agent Sessions window.

workstream-labs/workstreams · 45 tokens

component-fixtures

Use when creating or updating component fixtures for screenshot testing, or when designing UI components to be fixture-friendly. Covers fixture file structure, theming, service setup, CSS scoping, async rendering, and common pitfalls.

workstream-labs/workstreams · 47 tokens