User Manual

Complete reference for every setting, workspace option, and JSON configuration field available in EasyContextSwitch. Master the full power of automated context switching.

Windows 10 / 11 Schema v1.0 JSON-based config

Overview

EasyContextSwitch orchestrates your Windows development environments via workspace profiles — JSON files stored in %APPDATA%\EasyContextSwitch\workspaces\. When you activate a workspace, the engine runs your launch sequence (processes, apps, URLs) and tears down the previous workspace automatically.

1

Create a Workspace Profile

Use the New Workspace form in the app UI, or write a JSON file directly in the workspaces directory. Every profile requires a unique workspace_id, a human-readable name, and at least one launch step.

2

Assign a Global Hotkey (optional)

Set a hotkey value like Ctrl+Alt+A to activate the workspace from anywhere on the desktop, even without the EasyContextSwitch window in focus.

3

Click Activate or Press the Hotkey

The engine tears down any currently active workspace, then executes all launch steps in order. Window snapping, Docker orchestration, and URL opening all happen automatically.

Data Storage

All application data is stored locally on your machine — no cloud dependencies.

%APPDATA%\EasyContextSwitch\workspaces\

Workspace profile JSON files. Each file is named <workspace_id>.json.

%APPDATA%\EasyContextSwitch\settings.json

Global application settings (Docker auto-start, app auto-start, trigger rules).

%APPDATA%\EasyContextSwitch\license_info.json

Trial timing, license key, and per-workspace activation counts.

%APPDATA%\EasyContextSwitch\window_state.json

Persisted window position and size — restored automatically on next launch.

%APPDATA%\EasyContextSwitch\easyeditor-compose.yml

Auto-generated Docker Compose file for the built-in EasyEditor service.

On a typical Windows installation, %APPDATA% resolves to C:\Users\<YourUsername>\AppData\Roaming. You can type %APPDATA% directly into Windows Explorer's address bar to navigate there.

Activation Flow

Understanding the exact order of operations helps you design reliable workspace sequences.

1

Trigger

User clicks Activate on a workspace card, presses the registered global hotkey, or an auto-trigger rule fires (see Trigger Rules).

2

Teardown Previous Workspace

If another workspace is currently active, all its teardown_sequence steps run first — running cleanup commands and killing processes.

3

DPI Awareness Context

The engine sets the process DPI context via the Win32 API to ensure window coordinates map correctly across mixed-DPI multi-monitor setups.

4

Execute Launch Sequence

Steps run in ascending step order. background_process steps with wait_for_completion: true block until the command exits before the next step begins.

5

Window Polling & Snapping

For each application step with window_rules, a background goroutine polls every 200 ms (up to 15 s) for the window handle. Once found, SetWindowPos is called. Retry passes run at 300 ms and 1 s to override apps that restore their own positions.

Workspace Identity Fields

These top-level fields define a workspace profile's identity and global shortcut.

Field Type Status Description
workspace_id string Required Unique snake_case identifier for this workspace (e.g. proj_alpha_backend). Used as the filename: <workspace_id>.json. Must be unique across all profiles.
name string Required Human-readable display label shown in the workspaces dashboard (e.g. Project Alpha — Go Backend).
hotkey string Optional Global keyboard shortcut to activate this workspace from anywhere on the desktop. Format: Modifier+Key. Leave empty to disable. See Hotkey Format for valid values.
virtual_desktop int Optional Maps the workspace to a Windows Virtual Desktop number (1-indexed). When set, the engine will switch to the specified virtual desktop during activation. Omit or set to 0 to disable.

Launch Sequence

The launch_sequence array defines every operation that runs when activating this workspace. Steps execute in strictly ascending step order.

Field Type Status Description
step int Required Positive integer defining execution order. Steps are sorted ascending before running. Numbers do not need to be consecutive — e.g. 1, 5, 10 is valid.
type string Required The category of this launch step. One of: background_process, application, url, health_check. See Step Types below.
executable string Required* Path or command to execute. For background_process and application: full path or PATH-resolvable binary (e.g. powershell.exe, C:\...\Code.exe). For health_check: the HTTP/TCP endpoint to poll (e.g. http://localhost:8080/health). Not required for url steps — leave empty.
arguments string[] Optional Array of command-line arguments. Each argument is a separate string element — avoid combining arguments into one string. For url steps, this array holds the list of URLs to open.
wait_for_completion bool Optional When true, the engine blocks execution of subsequent steps until this process exits. Only applicable to background_process steps. Default: false (runs async).
window_rules object Optional Window positioning rules for GUI applications. Only effective on application steps. See Window Rules below.
timeout_seconds int Optional Maximum time in seconds to wait for a health_check step to respond successfully. Default: 30. The step fails and logs an error if the endpoint does not respond within this duration.
Step numbers must be greater than zero. Duplicate step numbers are allowed but the execution order between them is undefined. Use distinct integers to guarantee order.

Step Types

The type field on each launch step determines how the engine executes it.

background_process

Background Process

Runs a CLI command, shell script, or daemon. Use this for Docker Compose, npm scripts, build tools, or any process that should run silently in the background. Set wait_for_completion: true to block subsequent steps until it exits.

application

GUI Application

Launches a windowed application (IDE, database GUI, terminal, etc.) and optionally snaps its window to precise monitor coordinates using window_rules. The engine polls for the window handle after launch.

url

Browser URLs

Opens one or more URLs in the system default browser. List all URLs in the arguments array. The executable field is ignored and should be left empty. Each URL opens as a new tab.

health_check

Health Check

Polls an HTTP or TCP endpoint and blocks until it responds successfully. Use after starting a server to ensure it is ready before opening browser tabs or launching dependent apps. Set timeout_seconds to control the maximum wait time.

Step type examples
// background_process — run docker-compose, blocking next step
{
  "step": 1,
  "type": "background_process",
  "executable": "docker",
  "arguments": ["compose", "up", "-d"],
  "wait_for_completion": true
}

// health_check — wait for API to be ready
{
  "step": 2,
  "type": "health_check",
  "executable": "http://localhost:8080/health",
  "timeout_seconds": 30
}

// application — launch VS Code, snap to monitor 1
{
  "step": 3,
  "type": "application",
  "executable": "C:\\Users\\you\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe",
  "arguments": ["C:\\dev\\myproject"],
  "window_rules": { /* see Window Rules */ }
}

// url — open multiple tabs
{
  "step": 4,
  "type": "url",
  "executable": "",
  "arguments": ["http://localhost:8080", "https://github.com"]
}

Window Rules

The window_rules object, nested inside an application launch step, instructs the Win32 engine to find and reposition the launched application's window on the target monitor.

Field Type Status Description
title_match string Required Case-insensitive substring matched against the target window's title bar text. The engine uses this to identify the correct window handle among all running windows. Use a short, distinctive word from the expected title (e.g. "alpha" for a VS Code window titled "alpha — Visual Studio Code").
monitor int Required 1-indexed display number. Monitor 1 is typically the primary display. Use the System Settings panel in the app to view the detected monitor list and their indices.
x int32 Required Horizontal pixel offset of the window's top-left corner, relative to the target monitor's top-left origin. Set to 0 to align with the left edge of the monitor.
y int32 Required Vertical pixel offset of the window's top-left corner, relative to the target monitor's top-left origin. Set to 0 to align with the top edge of the monitor.
width int32 Required Desired window width in physical pixels. On a 1920×1080 display, setting width: 1920 makes the window span the full screen width.
height int32 Required Desired window height in physical pixels. On a 1920×1080 display, setting height: 1080 makes the window span the full screen height.
monitor: 1  (1920 × 1080)
(x:0, y:0) width: 140px height: 100px

Coordinates are relative to the target monitor's top-left corner. Use the Capture Current Layout feature in the app to read live window positions.

Pro tip: Use the Capture Current Layout button in the app settings to automatically read the X, Y, width, and height of all currently open windows. Copy these values directly into your workspace JSON.
window_rules example — left half of monitor 1
{
  "title_match": "myproject",
  "monitor": 1,
  "x": 0,
  "y": 0,
  "width": 960,
  "height": 1080
}

Teardown Sequence

The teardown_sequence array defines cleanup steps that run when switching away from this workspace. Use it to shut down services, kill processes, and reverse any changes made during activation.

Field Type Status Description
type string Required The teardown strategy. One of: command or kill_process. See Teardown Types below.
executable string Required* Path or name of the CLI executable to run. Required when type is command. Ignored when type is kill_process.
arguments string[] Optional Command-line arguments for the teardown command. Only applicable when type is command.
process_name string Required* Filename of the process to forcefully terminate (e.g. Code.exe, notepad.exe). Required when type is kill_process. The engine uses taskkill /F /IM internally.
Teardown steps are not ordered — there is no step field. They execute in array order. Teardown runs synchronously. Ensure your cleanup commands are reliable and exit cleanly, otherwise they may delay workspace switching.

Teardown Types

command

Run Cleanup Command

Executes a terminal command during teardown. Use for docker compose down, stopping databases, running cleanup scripts, or any shutdown procedure that requires a CLI invocation.

kill_process

Kill Process by Name

Forcefully terminates all instances of a process by executable filename using taskkill /F /IM <process_name>. Use for GUI apps or services that don't respond to graceful shutdown.

teardown_sequence example
"teardown_sequence": [
  {
    "type": "command",
    "executable": "docker",
    "arguments": ["compose", "-f", "C:\\dev\\alpha\\docker-compose.yml", "down"]
  },
  {
    "type": "kill_process",
    "process_name": "Code.exe"
  }
]

Virtual Desktop

The optional virtual_desktop field maps the workspace to a Windows Virtual Desktop. Set it to a positive integer to switch to that virtual desktop during activation.

Field Type Default Description
virtual_desktop int 0 (disabled) 1-indexed Virtual Desktop number. Windows supports up to 365 virtual desktops. Create virtual desktops in Windows via Win + TabNew desktop. Set to 0 or omit to leave the active virtual desktop unchanged.
Virtual Desktop support requires Windows 10 version 1607 or later. The virtual_desktop field is ignored on older Windows versions.

Install from Templates

Templates provide pre-configured workspace profiles that you can install with a single click. Each template includes a complete launch sequence, teardown steps, hotkeys, and window rules — ready to use as-is or customised to your environment.

1

Open the Templates Tab

Navigate to the Templates tab in the sidebar. All available templates are listed as cards with a name, description, and Install button.

2

Click Install

Click the Install button on any template card. The engine writes the workspace JSON file to %APPDATA%\EasyContextSwitch\workspaces\ and registers the defined hotkey automatically. For Docker-based templates, the required Docker Compose file is also written to disk.

3

Customise & Activate

Once installed, the workspace appears in your workspaces list. Open the Editor tab to customise paths, arguments, window positions, and hotkeys to match your environment — then activate it.

Pro tip: Templates use generic placeholder paths like C:\Users\Developer\.... After installing, update all executable paths, project directories, and repository URLs to match your machine.

Available Templates

EasyContextSwitch ships with 8 built-in workspace templates covering common development scenarios. Each template is a fully functional example — install it, tweak the paths, and start working.

easyeditor_docker_flow

EasyEditor Docker

Automated Docker Compose flow that spins up an EasyEditor container and opens localhost:3024 in your browser. Includes a teardown step to bring down the Docker service. The required easyeditor-compose.yml is auto-generated on install.

operations_terminal

Operations Terminal

Launches a custom terminal application inside a styled cmd/pwsh terminal session with window snapping to monitor 1. Includes a kill_process teardown for clean shutdown.

easycontextswitch_ide

ContextSwitch – Code IDE

Opens VS Code with a project directory, runs a git pull in the background, and launches the GitHub repository page in a browser tab. Full IDE developer bootstrap.

kiro_ide

Kiro IDE

Quick developer bootstrap for the Kiro IDE — opens a project directory, snaps the window to a specified monitor area, and opens the repository in a browser.

vmware_workstation_fedora

Fedora Virtual Machine

Automates VMware Workstation to boot a Fedora VM in full window scaling. Teardown gracefully shuts down the VM via vmrun stop ... soft before killing the VMware process.

wsl_go_ubuntu

WSL Go Ubuntu

Boots a WSL Ubuntu instance, restores and pulls Git repositories, launches VS Code with a remote WSL folder URI, and opens a Windows Terminal session connected to the WSL distribution.

wsl_go_ubuntu_scmd

WSL Go SCMD Dev

Spins up WSL Ubuntu for backend Go development, maps network mounts, and sets up VS Code with remote WSL extensions alongside a Windows Terminal shell.

proj_alpha_backend

Project Alpha – Go Backend

Full-stack backend workspace: Docker Compose containers, VS Code editor with window snapping, and browser tabs for health endpoints and GitHub. Teardown reverses everything cleanly.

Installing a template that uses the same workspace_id as an existing workspace will overwrite the existing workspace file. Check your current workspaces list before installing.

Auto-Start Docker

Stored in settings.json under the key auto_start_docker. When enabled, EasyContextSwitch automatically starts Docker Desktop on application launch if the Docker daemon is not already running.

auto_start_docker

Auto-Start Docker Desktop

When true, the app checks whether Docker is running on startup by executing docker info. If Docker is not running, it launches Docker Desktop from its standard installation path: C:\Program Files\Docker\Docker\Docker Desktop.exe.

Default: false  ·  Type: bool  ·  JSON key: auto_start_docker

This setting only works if Docker Desktop is installed at the standard Windows path. Custom Docker installations at non-standard paths will not be detected. The app logs an error if Docker Desktop is not found.
settings.json — auto-start enabled
{
  "auto_start_docker": true,
  "trigger_rules": []
}

Auto-Start App

Stored in settings.json under the key auto_start_app. When enabled, EasyContextSwitch automatically launches when Windows starts by adding an entry to the Windows Registry under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run.

auto_start_app

Launch on Windows Startup

When true, the application writes a registry key to the Windows Run hive so that EasyContextSwitch starts automatically when the user logs in. When set to false, the registry key is removed. The setting is synced to the registry every time the app starts and whenever you toggle the checkbox in the Settings panel.

Default: false  ·  Type: bool  ·  JSON key: auto_start_app

The registry entry uses the full path to the current easycontextswitch.exe executable. If you move the application to a different directory, toggle the setting off and back on to update the registry path.
settings.json — both auto-start options enabled
{
  "auto_start_docker": true,
  "auto_start_app": true,
  "trigger_rules": []
}

Capture Current Layout

The Capture Current Layout button in the workspace editor reads the position, size, and title of every visible window on your desktop. Use it to quickly fill in window_rules values without manually measuring pixels.

1

Arrange Your Windows

Position all the application windows on your monitors exactly where you want them. Resize them to the desired dimensions.

2

Click "Capture Current Layout"

In the workspace Editor tab, click the Capture Current Layout button. The engine calls the Win32 API to enumerate all visible top-level windows and capture their title, executable path, monitor assignment, X/Y position, width, and height.

3

Copy Values into Window Rules

The captured windows appear in a modal with all coordinates displayed. Copy the values directly into your workspace step's window_rules fields, or use them as a reference to fine-tune positioning.

Captured Field Type Description
title string The window's title bar text — use as the value for title_match.
executable string Full path to the process executable that owns the window.
monitor int The 1-indexed monitor that the window is currently displayed on.
x / y int32 Top-left corner pixel coordinates relative to the monitor's origin.
width / height int32 Window dimensions in physical pixels.
Pro tip: Capture your layout once, then paste the values into multiple workspace profiles that should use the same screen arrangement. This saves time when you use consistent window positions across projects.

Trigger Rules

Trigger rules automatically activate a workspace when a specific application gains focus. The engine polls the active foreground window every 3 seconds and activates the mapped workspace if the focused process matches a rule.

Field Type Status Description
process_name string Required Executable filename to watch (e.g. code.exe, devenv.exe). Matching is case-insensitive. Only the base filename is compared — do not include the full path.
workspace_id string Required The workspace_id of the workspace to auto-activate when this process gains foreground focus. Must match an existing workspace profile exactly.

Example trigger rule mappings:

code.exe proj_alpha_backend VS Code → Backend workspace
devenv.exe dotnet_frontend Visual Studio → Frontend workspace
datagrip64.exe db_admin_flow DataGrip → DB Admin workspace
A trigger rule only fires if the mapped workspace is not already active. The engine will not re-activate the current workspace, preventing infinite loops.
settings.json — trigger rules example
{
  "auto_start_docker": false,
  "trigger_rules": [
    {
      "process_name": "code.exe",
      "workspace_id": "proj_alpha_backend"
    },
    {
      "process_name": "devenv.exe",
      "workspace_id": "dotnet_frontend"
    }
  ]
}

Hotkey Format

The hotkey field uses a +-delimited string of one or more modifier keys followed by a regular key. Hotkeys are registered system-wide and fire regardless of which window is in focus.

Example valid hotkey values:

Ctrl+ Alt+ A Ctrl+ Shift+ F1 Alt+ F9 Ctrl+ Alt+ 1
Each hotkey must be unique across all workspace profiles. Attempting to register a hotkey already in use by another profile or by the operating system will fail and log an [ERROR] message in the console. Windows reserves certain key combinations for system use.

Supported Modifiers & Keys

Category Valid Values
Modifier Keys Ctrl, Alt, Shift, Win
Letter Keys AZ (uppercase)
Number Keys 09
Function Keys F1F12
The Ctrl+Alt+ prefix is recommended for workspace hotkeys as it is rarely used by other applications and avoids conflicts with common shortcuts like Ctrl+C or Alt+F4.

Import & Export

Workspace configurations can be backed up and shared as ZIP archives containing all .json workspace files.

Export Workspaces

Export All Workspaces to ZIP

Opens a Save dialog to choose a destination. All workspace JSON files from %APPDATA%\EasyContextSwitch\workspaces\ are bundled into a single ZIP archive. The default filename is easycontextswitch_workspaces_backup.zip. Settings (settings.json) are not included.

Import Workspaces

Import Workspaces from ZIP

Opens a File picker to select a previously exported ZIP. All .json files inside are extracted into the workspaces directory. If a file with the same name already exists, it is overwritten. Hotkeys defined in imported workspaces are registered immediately. Invalid JSON files are silently skipped.

You can also manually copy individual .json files between machines — place them in the %APPDATA%\EasyContextSwitch\workspaces\ directory and restart the app for them to appear.

Trial Period

EasyContextSwitch starts with a 14-day free trial on first install. During the trial, all features are fully unlocked with no limitations.

Property Value Description
Trial Duration 14 days Full access to all features — workspace creation, editing, activation, templates, import/export, and all settings.
Degraded Mode Post-trial After the trial expires without a license key, workspace editing and deletion are locked. Only your most frequently used workspace can still be activated. All other workspaces are restricted.
Clock Protection Active Rolling the system clock backward does not extend the trial. The engine tracks the furthest-seen timestamp and calculates days elapsed from that value.
%APPDATA%\EasyContextSwitch\license_info.json

Stores trial start time, last-checked timestamp, license key, and per-workspace activation counts.

The trial status is displayed in the Settings panel of the app, showing days remaining, current license state, and your most-used workspace. A progress bar visualizes how much trial time is left.

License Key

License keys are validated offline using a cryptographic checksum algorithm — no internet connection or account required. Enter your key in the Settings panel to unlock the application permanently.

Detail Description
Format Keys begin with the prefix ECS- followed by an alphanumeric payload with an embedded checksum. Example: ECS-XXXX-XXXX-XXXX. The key is case-insensitive and trimmed of whitespace.
Validation The app splits the payload, hashes the first portion with a secret salt using SHA-256, and verifies the checksum digits match. No server call is made.
Registration Navigate to Settings → License and paste your key into the input field. Click Register. If valid, the key is persisted to license_info.json and all restrictions are immediately removed.
Persistence The key is stored locally in license_info.json. It is verified on every app launch — no expiry date.
License keys are tied to the offline validation algorithm. Do not share or redistribute your key. If you need a key for a second machine, contact the project maintainers.
Activation Tracking

Per-Workspace Activation Counts

The engine tracks how many times each workspace has been activated. In degraded mode (expired trial, no license), only the most frequently activated workspace remains usable. These counts are stored in license_info.json under the activation_counts field.

License Instructions & Terms

EasyContextSwitch is distributed under a balanced open-source license combining the GNU AGPL-3.0 with the Commons Clause v1.0 (Non-Commercial restriction) and a Trademark Clause.

1. Commons Clause — Non-Commercial Use Only

You have full access to study, modify, and build the source code, but you do NOT have the right to Sell the Software. Selling means providing EasyContextSwitch or any derivative software to third parties for a fee or other commercial consideration (including paid consulting, hosting setups, or support contracts).

2. Trademark Restrictions

The names EasyContextSwitch and its logos are protected project trademarks. If you fork the repository or distribute custom versions, you must rename the project entirely and may not use the original trademark elements or claim endorsement from the project creators.

Allowed vs. Prohibited Uses

✔ What is ALLOWED:

  • Using EasyContextSwitch internally within your enterprise or team at no cost.
  • Modifying the codebase to fit your exact internal development infrastructure needs.
  • Sharing your code modifications or feature improvements with the community.
  • Distributing modified copies for non-commercial purposes with proper attribution.

✖ What is PROHIBITED:

  • Selling the compiled binaries of EasyContextSwitch or charging fees to download it.
  • Offering hosted setup services or configuration assistance as a paid commercial utility.
  • Creating paid "Enterprise" or "Pro" commercial additions using this code base.
  • Rebranding, wrapping, and reselling the project under your own name for commercial fees.
GNU AFFERO GENERAL PUBLIC LICENSE
Version 3, 19 November 2007

Copyright (C) 2026 EasyEditor, EasyAI, EasyGit, EasyNotes Contributors

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License
along with this program.  If not, see <https://www.gnu.org/licenses/>.

---

ADDITIONAL TERMS - COMMONS CLAUSE + TRADEMARK

1. COMMONS CLAUSE - NON-COMMERCIAL USE ONLY

The Software is provided to you by the Licensor under the License, as defined
below, subject to the following condition.

Without limiting other conditions in the License, the grant of rights under the
License will not include, and the License does not grant to you, the right to
Sell the Software.

For purposes of the foregoing, "Sell" means practicing any or all of the rights
granted to you under the License to provide to third parties, for a fee or other
consideration (including without limitation fees for hosting or consulting/
support services related to the Software), a product or service whose value
derives, entirely or substantially, from the functionality of the Software.

Any license notice or attribution required by the License must also include
this Commons Clause License Condition notice.

2. TRADEMARK CLAUSE

The names EasyContextSwitch and its logo are trademark of the project.

You may NOT:
1. Use the names "EasyContextSwitch" or any confusingly similar names for derivative works
2. Use the project's logos or any similar branding for derivative works
3. Claim that your derivative work is endorsed by or affiliated with EasyContextSwitch
4. Redistribute EasyContextSwitch under a different name as if it were your own product
5. Sell EasyContextSwitch or any derivative work

You MAY:
1. Modify the source code and use it internally
2. Distribute modified versions for non-commercial purposes (with attribution)
3. Use EasyContextSwitch as a component in your project (with proper attribution)
4. Create forks for development purposes (clearly labeled as forks)
5. Contribute improvements back to the project

---

For Commons Clause information, see:
https://commonsclause.com/

For the full AGPL-3.0 license text, visit:
https://www.gnu.org/licenses/agpl-3.0.html

Full JSON Example

A complete, production-ready workspace profile for a Go backend project demonstrating all available configuration fields.

proj_alpha_backend.json — complete example
{
  "workspace_id": "proj_alpha_backend",
  "name": "Project Alpha — Go Backend",
  "hotkey": "Ctrl+Alt+A",
  "virtual_desktop": 2,

  "launch_sequence": [
    {
      "step": 1,
      "type": "background_process",
      "executable": "docker",
      "arguments": ["compose", "-f", "C:\\dev\\alpha\\docker-compose.yml", "up", "-d"],
      "wait_for_completion": true
    },
    {
      "step": 2,
      "type": "health_check",
      "executable": "http://localhost:5432",
      "timeout_seconds": 30
    },
    {
      "step": 3,
      "type": "application",
      "executable": "C:\\Users\\you\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe",
      "arguments": ["C:\\dev\\alpha"],
      "window_rules": {
        "title_match": "alpha",
        "monitor": 1,
        "x": 0,
        "y": 0,
        "width": 1280,
        "height": 1440
      }
    },
    {
      "step": 4,
      "type": "url",
      "executable": "",
      "arguments": [
        "http://localhost:8080/health",
        "https://github.com/your-org/alpha"
      ]
    }
  ],

  "teardown_sequence": [
    {
      "type": "command",
      "executable": "docker",
      "arguments": ["compose", "-f", "C:\\dev\\alpha\\docker-compose.yml", "down"]
    },
    {
      "type": "kill_process",
      "process_name": "Code.exe"
    }
  ]
}

Quick Reference

Step Types

background_process
application
url
health_check

Teardown Types

command
kill_process

Hotkey Modifiers

Ctrl
Alt
Shift
Win

Config Directory

%APPDATA%\EasyContextSwitch\

File Naming

<workspace_id>.json

Window Poll Interval

200 ms (max 15 s)

Trigger Poll Interval

Every 3 seconds

Export Format

.zip (JSON files only)

Built-in Templates

8 workspace templates

Settings Fields

auto_start_docker
auto_start_app
trigger_rules

Trial Period

14 days (full access)

License File

license_info.json