I built a Postman-like workspace for local scripts

yunate — Tue, 22 Sep 2026 09:29:21 +0000

Windows Terminal is great, but I wanted a better way to manage my scripts

Windows Terminal is already a very good terminal. I use it regularly, and I do not want to replace it.

The part that kept bothering me happened before I could actually run anything. I had to remember where a script was stored, navigate to its directory, type or paste the path, and then provide the right values for the environment I was working with. As my collection grew, I also ended up with scripts scattered across folders and slightly different copies of the same script.

I wanted something closer to the workflow I use in Postman, but for local scripts instead of HTTP requests. That led me to build a Windows application called MagicHat.

A workspace for reusable scripts

The Command page organizes scripts in a folder tree and lets me edit and run them without first locating them from the command line. It currently supports PowerShell, JavaScript, Python, and batch scripts, although PowerShell is the main reason I started building it.

The storage location is configurable. MagicHat does not require scripts to live in an internal database, so I can keep a workspace in a normal directory and manage it with Git. This makes the scripts portable and keeps their history outside the application.

Postman-like parameter groups

Many of my scripts are structurally identical across development, test, and production environments. Usually only URLs, IDs, paths, or tokens change.

MagicHat lets a command have multiple parameter groups. A script can reference values with macros such as mh{baseUrl} or mh{accessToken}:

$headers = @{
    Authorization = "Bearer mh{accessToken}"
}

Invoke-RestMethod `
    -Method Post `
    -Uri "mh{baseUrl}/api/jobs/mh{jobId}" `
    -Headers $headers

I can switch parameter groups without editing the script. Macro values can also reference other macros, which is useful when several endpoints share the same base path.

Letting scripts update shared state

Some values are only known after a script runs. An authentication script, for example, might receive a new access token that should be reused by later commands.

Inside a MagicHat PowerShell terminal, a script can persist a parameter value with:

mhsetenv AccessToken $newToken

This avoids manually copying the result back into a parameter editor after every run.

A saved command can also synchronously call another command:

mhcall "./Get-AccessToken.mh"

That makes it possible to compose small scripts while keeping each one independently runnable.

Recurring automation

I later added a Task Center for scripts or actions that need to run repeatedly.

A simple example is a periodic task that presses F15 and slightly moves the mouse. It can keep a workstation or application from entering an idle state. The same mechanism can be used for maintenance scripts, polling, cleanup, or other recurring local automation.

Small tools I kept reaching for

MagicHat also includes a Tools page for small utilities I often need while working, such as JSON and YAML formatting, Base64, URL conversion, regular-expression testing, hashes, timestamps, UUID generation, QR codes, OCR, and file-occupancy inspection.

These tools are secondary to script management, but keeping them in the same local application reduces context switching for me.

Where it is now

MagicHat is a local Windows application built for my own workflow, and I am still learning whether the same approach is useful to other developers.

I would especially like feedback from people who maintain personal or team script repositories:

How do you organize scripts that you run repeatedly?
How do you manage environment-specific values?
Do you prefer plain repositories and modules, or would a visual workspace help?
Which part of this workflow feels useful, and which part feels unnecessary?

Project and download:

https://github.com/ddmagichat/magichat-release/releases/tag/latest

DEV Community: yunate