DEV Community: Scott Williams

Audit Windows startup entries with PowerShell without breaking anything: read-only first, -WhatIf, a JSON backup and an undo

Scott Williams — Thu, 29 Oct 2026 15:23:15 +0000

AI disclosure: this post was written with AI assistance. The code was syntax-checked and linted, and its logic was tested with simulated registry objects, but it has not yet been run on Windows: not against a real registry, and not on Windows PowerShell 5.1. Read it before you run it, and try it with -WhatIf first.

Settings > Apps > Startup and Task Manager's Startup apps tab are the right first stop when a Windows PC is slow after sign-in. Use them first. But sometimes something still starts at sign-in and you can't see where it comes from, or Settings shows an entry called "We couldn't find this app" left behind by something you uninstalled.

Microsoft documents where those entries live: the Run registry keys and the two Startup folders. This post builds three small PowerShell functions around them:

Get-StartupEntry: a read-only list. Changes nothing.
Disable-RunEntry: removes one Run value, but only after saving it to a JSON file, and it supports -WhatIf and -Confirm.
Restore-RunEntry: puts the value back from that JSON file.

The pattern (report first, preview with -WhatIf, back up, then change, and keep an undo) is worth copying for any script that touches the registry.

Where startup entries live

From Microsoft's startup apps page and the Run/RunOnce documentation:

Location	Scope
`HKCU\Software\Microsoft\Windows\CurrentVersion\Run`	Current user
`HKLM\Software\Microsoft\Windows\CurrentVersion\Run`	All users
`HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run`	All users, 32-bit apps on 64-bit Windows
`...\RunOnce` (HKCU and HKLM)	Runs once at the next sign-in, then the value is deleted
`shell:startup` = `%AppData%\Microsoft\Windows\Start Menu\Programs\Startup`	Current user's Startup folder
`shell:common startup` = `%ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup`	All users' Startup folder

This is not the complete list of ways a program can start (scheduled tasks and services are others), but it covers what Settings' startup list points you to.

Step 1: a read-only audit

$runKeys = @(
    'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run'
    'HKCU:\Software\Microsoft\Windows\CurrentVersion\RunOnce'
    'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run'
    'HKLM:\Software\Microsoft\Windows\CurrentVersion\RunOnce'
    'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Run'
)

function Get-StartupEntry {
    [CmdletBinding()]
    param()

    foreach ($key in $runKeys) {
        if (-not (Test-Path -LiteralPath $key)) { continue }
        $item = Get-Item -LiteralPath $key
        foreach ($name in $item.GetValueNames()) {
            if ($name -eq '') { continue }   # skip the (Default) value
            [pscustomobject]@{
                Source   = 'Registry'
                Location = $key
                Name     = $name
                # Read the raw text, so %ProgramFiles% etc. are not expanded
                Command  = $item.GetValue($name, $null, 'DoNotExpandEnvironmentNames')
            }
        }
    }

    $folders = [Environment]::GetFolderPath('Startup'),
               [Environment]::GetFolderPath('CommonStartup')
    foreach ($folder in $folders) {
        if (-not $folder -or -not (Test-Path -LiteralPath $folder)) { continue }
        Get-ChildItem -LiteralPath $folder -File |
            Where-Object Name -ne 'desktop.ini' |
            ForEach-Object {
                [pscustomobject]@{
                    Source   = 'StartupFolder'
                    Location = $folder
                    Name     = $_.Name
                    Command  = $_.FullName
                }
            }
    }
}

Run it in a normal (non-admin) PowerShell window. Reading HKLM doesn't need admin rights:

Get-StartupEntry | Format-Table -AutoSize

A few details that matter:

GetValue(..., 'DoNotExpandEnvironmentNames') returns the command exactly as stored, so %LOCALAPPDATA%\... stays as written. You want the raw text in a backup, otherwise restoring it changes the value's meaning.
[Environment]::GetFolderPath('Startup') and 'CommonStartup' resolve the two Startup folders without hard-coding paths.
This list doesn't show the On/Off state you see in Settings or Task Manager. Cross-check there before you remove anything. If an entry can be turned off with the toggle, use the toggle. It's simpler and you can undo it with one click.

Windows also exposes a combined view through WMI, which is handy as a second opinion:

Get-CimInstance -ClassName Win32_StartupCommand |
    Select-Object Name, Command, Location, User

Step 2: remove one Run value, safely

Only do this for an entry you understand: typically a leftover that points to a program you have already uninstalled. Don't remove security software, and look up anything you don't recognise first. Microsoft warns that editing the registry can have unintended consequences and says to back it up first. This function makes the backup for you, for the one value it changes.

function Disable-RunEntry {
    [CmdletBinding(SupportsShouldProcess, ConfirmImpact = 'Medium')]
    param(
        [Parameter(Mandatory)] [string] $Key,
        [Parameter(Mandatory)] [string] $Name,
        [string] $BackupDir = (Join-Path $env:LOCALAPPDATA 'StartupBackups')
    )

    $item = Get-Item -LiteralPath $Key -ErrorAction Stop
    if ($item.GetValueNames() -notcontains $Name) {
        throw "No value named '$Name' under $Key"
    }

    # Capture everything needed to put it back, before touching anything.
    $backup = [pscustomobject]@{
        Key     = $Key
        Name    = $Name
        Value   = $item.GetValue($Name, $null, 'DoNotExpandEnvironmentNames')
        Kind    = $item.GetValueKind($Name).ToString()
        SavedAt = (Get-Date).ToString('o')
    }

    if ($PSCmdlet.ShouldProcess("$Key\$Name", 'Remove startup value (backup is saved first)')) {
        New-Item -ItemType Directory -Path $BackupDir -Force -ErrorAction Stop -Confirm:$false | Out-Null
        $safeName = $Name -replace '[^\w.-]', '_'
        $file = Join-Path $BackupDir ('{0}_{1}.json' -f $safeName, (Get-Date -Format 'yyyyMMdd-HHmmss'))
        $backup | ConvertTo-Json | Set-Content -LiteralPath $file -Encoding UTF8 -ErrorAction Stop -Confirm:$false

        Remove-ItemProperty -LiteralPath $Key -Name $Name -ErrorAction Stop -Confirm:$false
        # Output the backup path so you can pass it straight to Restore-RunEntry
        [pscustomobject]@{ Removed = "$Key\$Name"; BackupFile = $file }
    }
}

Three things make this safe to run:

SupportsShouldProcess gives the function -WhatIf and -Confirm for free. Nothing inside the if ($PSCmdlet.ShouldProcess(...)) block runs during -WhatIf.
The backup is written before the delete. New-Item and Set-Content use -ErrorAction Stop, so if the backup folder or file can't be written, the function stops and Remove-ItemProperty never runs. Without -ErrorAction Stop this wouldn't hold: most write failures (access denied, disk full) are non-terminating errors, and the next line would still run.
The value kind is saved too (String vs ExpandString), so the restore writes back exactly the same type.

The inner -Confirm:$false calls stop you being asked three times when you run with -Confirm. You confirm once, at the ShouldProcess prompt.

Preview first, then run it for real:

Disable-RunEntry -Key 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' -Name 'SomeOldUpdater' -WhatIf
Disable-RunEntry -Key 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' -Name 'SomeOldUpdater'

The second command prints the path of the backup file. Entries under HKLM: need an administrator PowerShell window.

Step 3: undo

function Restore-RunEntry {
    [CmdletBinding(SupportsShouldProcess, ConfirmImpact = 'Medium')]
    param([Parameter(Mandatory)] [string] $BackupFile)

    $b = Get-Content -LiteralPath $BackupFile -Raw -ErrorAction Stop | ConvertFrom-Json
    if ($PSCmdlet.ShouldProcess("$($b.Key)\$($b.Name)", 'Restore startup value')) {
        New-ItemProperty -LiteralPath $b.Key -Name $b.Name -Value $b.Value `
            -PropertyType $b.Kind -Force -ErrorAction Stop -Confirm:$false | Out-Null
        [pscustomobject]@{ Restored = "$($b.Key)\$($b.Name)"; Value = $b.Value }
    }
}

Restore-RunEntry -BackupFile "$env:LOCALAPPDATA\StartupBackups\SomeOldUpdater_20261029-101500.json" -WhatIf
Restore-RunEntry -BackupFile "$env:LOCALAPPDATA\StartupBackups\SomeOldUpdater_20261029-101500.json"

What about the Startup folders?

Don't delete shortcuts there. Move them to a backup folder instead, and move them back to undo:

$backup = Join-Path $env:LOCALAPPDATA 'StartupBackups\StartupFolder'
New-Item -ItemType Directory -Path $backup -Force | Out-Null
Move-Item -LiteralPath (Join-Path ([Environment]::GetFolderPath('Startup')) 'SomeApp.lnk') -Destination $backup -WhatIf

Remove -WhatIf when the preview looks right. The all-users folder needs admin rights.

Limits, honestly

The code was tested with PowerShell 7 on Linux, using fake registry objects. It parsed cleanly, PSScriptAnalyzer reported nothing, and Pester tests of the backup/remove/restore logic passed (including a simulated failed backup write, which stops the removal). It has not been run against a real Windows registry or on Windows PowerShell 5.1. Try it with -WhatIf first, and make a restore point if you are nervous.
It only covers the Run/RunOnce keys and Startup folders, not scheduled tasks, services or per-app settings.
It removes one value at a time on purpose. Bulk "cleaners" are how people end up with a missing touchpad or audio driver panel after a restart.

Sources (Microsoft)

Configure startup applications in Windows (Settings, Task Manager impact levels, Startup folders, registry locations, back up the registry first): https://support.microsoft.com/en-us/windows/experience/startup-boot/configure-startup-applications-in-windows
Run and RunOnce registry keys: https://learn.microsoft.com/en-us/windows/win32/setupapi/run-and-runonce-registry-keys
Win32_StartupCommand class: https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-startupcommand
Everything you wanted to know about ShouldProcess: https://learn.microsoft.com/en-us/powershell/scripting/learn/deep-dives/everything-about-shouldprocess

This article was created with the help of AI. Not affiliated with or endorsed by Microsoft.

Fetching user-supplied URLs from a Cloudflare Worker without getting burned

Scott Williams — Thu, 29 Oct 2026 14:04:16 +0000

AI disclosure: this post was written with AI assistance (drafting, code and editing). The code comes from a project whose unit and integration tests I ran on October 28, 2026.

Any API that takes a URL and fetches it (link previews, metadata extraction, uptime checks, feed readers) is a request-forgery machine unless you put rules around it. Running on Cloudflare Workers removes some risks, since there is no cloud metadata service sitting on localhost, but not all of them. Your Worker can still be pointed at internal hostnames, at origins that only trust Cloudflare IPs, or at a 5 GB file.

These are the checks I ended up with, in the order a request hits them. The snippets are trimmed; bad, blocked and tooLarge are small helpers that build error responses.

1. Validate the URL before you touch the network

if (u.protocol !== 'http:' && u.protocol !== 'https:') throw bad('Only http and https URLs are supported.');
if (u.username || u.password) throw bad('URLs with credentials are not allowed.');
if (u.port && u.port !== '80' && u.port !== '443') throw blocked('Only ports 80 and 443 are allowed.');

Then reject hostnames that can never be public: localhost, single-label names, and suffixes such as .local, .internal, .lan, .home.arpa, .test, .invalid and .onion. Strip a trailing dot first. localhost. is a valid way to write localhost.

2. Resolve the name and check every address

A hostname can point anywhere, so check where it resolves. Workers have no dns.lookup, but DNS over HTTPS works with a plain fetch:

async function doh(name: string, type: 'A' | 'AAAA'): Promise<string[]> {
  const r = await fetch(`https://cloudflare-dns.com/dns-query?name=${encodeURIComponent(name)}&type=${type}`, {
    headers: { accept: 'application/dns-json' },
    signal: AbortSignal.timeout(5000),
  });
  const j: any = await r.json();
  const want = type === 'A' ? 1 : 28;
  return (j.Answer || []).filter((a: any) => a.type === want).map((a: any) => String(a.data));
}

Query A and AAAA in parallel and reject the request if any answer is non-public. "Any", not "the first one": an attacker controls the DNS records and can mix a public and a private address.

The IPv4 blocklist is the usual set: 0/8, 10/8, 100.64/10, 127/8, 169.254/16, 172.16/12, 192.168/16, 192.0.0/24, 192.88.99/24, 198.18/15, the three documentation ranges, multicast and 240/4. IPv6 is where most hand-rolled checks leak, because IPv4 can hide inside it. Decode and re-check the embedded IPv4 address for:

IPv4-mapped ::ffff:127.0.0.1
the deprecated IPv4-compatible form ::127.0.0.1
NAT64 64:ff9b::/96
6to4 2002::/16, where the IPv4 address sits in the second and third groups

Then block ::, ::1, fc00::/7, fe80::/10, fec0::/10, ff00::/8, 2001:db8::/32 and 2001::/23. Write unit tests for each form. Parsing :: compression and embedded dotted quads is easy to get subtly wrong.

Treat anything you cannot parse as unsafe.

3. Follow redirects yourself

fetch follows redirects by default, which skips every check above for the second hop. Turn that off and loop:

const seen = new Set<string>([url.href]);
for (let hop = 0; ; hop++) {
  await assertPublicUrl(url);            // steps 1 and 2, on every hop
  const res = await fetch(url, { redirect: 'manual', signal: AbortSignal.timeout(timeoutMs) });
  if (res.status < 300 || res.status > 399 || !res.headers.get('location')) return res;
  if (hop >= maxRedirects) throw new Error('too many redirects');
  url = new URL(res.headers.get('location')!, url);   // Location may be relative
  if (seen.has(url.href)) throw new Error('redirect loop');
  seen.add(url.href);
}

Return the redirect chain to the caller as well. It makes debugging much easier for API users.

There is a gap I have not closed: DNS rebinding. The Worker checks the name, then fetch resolves it again, and a hostile DNS server with a zero TTL can answer differently the second time. Workers do not let you pin the connection to the IP you checked, and a fetch to a bare IP breaks TLS and virtual hosting. If your threat model is serious, put the fetcher behind an egress proxy that does the resolution and the check in one step.

4. Cap time and bytes

content-length is a hint, not a promise. Reject early when it is present and too large, then enforce the cap while streaming:

const reader = res.body!.getReader();
let total = 0;
const chunks: Uint8Array[] = [];
for (;;) {
  const { done, value } = await reader.read();
  if (done) break;
  if (total + value.byteLength > maxBytes) { await reader.cancel(); throw tooLarge(maxBytes); }
  chunks.push(value);
  total += value.byteLength;
}

Gzipped sitemaps need the same treatment after decompression (DecompressionStream('gzip')), or a few kilobytes of input can expand into gigabytes. Pass every fetch an AbortSignal.timeout() too.

Also mind the plan limits. On the Workers Free plan a request gets 10 ms of CPU time and 50 subrequests, according to the pricing and limits pages. Two DoH lookups per hop count against the subrequest limit, and parsing a large PDF or sitemap does not fit in 10 ms. A small in-memory DNS cache with a 60-second lifetime helps with the first problem. The second needs the paid plan.

5. Respect robots.txt properly

If your API crawls on behalf of users, honor robots.txt. RFC 9309 standardized the rules in 2022, and a few of them differ from what older parsers do:

Matching: the most specific rule (the longest pattern) wins. When an Allow and a Disallow are equally specific, Allow should win. * matches any sequence and a trailing $ anchors the end.
Groups: use the group whose user-agent matches your product token, and fall back to * only when none does. Several groups for the same agent are merged.
Fetching robots.txt: a 4xx response means no restrictions. A 5xx response or a network failure means you must assume everything is disallowed. Follow at least five redirects, and parse at least the first 500 KiB.
/robots.txt itself is always allowed.

The matcher is short. Compile each pattern into an anchored regex, and keep the raw pattern length to compare specificity:

function compile(pattern: string): RegExp {
  const anchored = pattern.endsWith('$');
  const body = (anchored ? pattern.slice(0, -1) : pattern)
    .split('*').map((p) => p.replace(/[.+?^${}()|[\]\\]/g, '\\$&')).join('.*');
  return new RegExp('^' + body + (anchored ? '$' : ''));
}

canFetch(token: string, url: string): boolean {
  if (this.disallowAll) return false;          // robots.txt returned 5xx or was unreachable
  const u = new URL(url);
  if (u.pathname === '/robots.txt') return true;
  const path = decodeURIComponent(u.pathname) + u.search;
  let best = -1, allow = true;
  for (const r of this.rulesFor(token)) {
    if (r.rx.test(path) && (r.pattern.length > best || (r.pattern.length === best && r.allow))) {
      best = r.pattern.length;
      allow = r.allow;
    }
  }
  return allow;
}

Ignore empty Disallow: lines (they mean "allow everything"), and wrap decodeURIComponent in a try/catch, because real-world paths contain stray % signs.

Testing

Three layers were worth writing:

Pure unit tests for the robots matcher: group selection by product token, longest match, an Allow/Disallow tie, * and $ patterns, an empty Disallow, and percent-encoded paths.
Unit tests with a stubbed fetch for the network logic: a public URL that 302s to 169.254.169.254, a 301 to http://[::ffff:7f00:1]/ (127.0.0.1 written as IPv4-mapped IPv6 in hex), a robots.txt that returns 503, a robots.txt behind a redirect, and a redirect loop.
Integration tests against wrangler dev with real public URLs and blocked targets, to confirm the checks stop what they should without blocking legitimate sites.

One gap I would add next: a test for a body that is larger than its content-length header claims.

This article was created with the help of AI. The code was tested by me before publishing.

Reading Greenhouse, Lever and Ashby job boards from their public JSON endpoints

Scott Williams — Wed, 28 Oct 2026 05:13:52 +0000

AI disclosure: this post was written with AI assistance (drafting and editing). I ran every request and code sample below myself on October 28, 2026 and checked the output.

If you want a list of open jobs at a set of companies, you usually do not need a headless browser. Most tech companies host their career page on an applicant tracking system (ATS), and three of the most common ones, Greenhouse, Lever and Ashby, expose the same postings their career pages render as plain JSON. No API key, no login.

This post covers the three endpoints, the fields worth keeping, and a small reader that turns all three into one shape.

1. Find the board name

The board name is in the career page URL:

ATS	Career page looks like	Board name
Greenhouse	`boards.greenhouse.io/airbnb` or `job-boards.greenhouse.io/airbnb`	`airbnb`
Lever	`jobs.lever.co/spotify`	`spotify`
Ashby	`jobs.ashbyhq.com/ramp`	`ramp`

If a company uses its own domain, view the page source and search for greenhouse, lever.co or ashbyhq. The embed script or the apply links usually give it away.

2. The endpoints

Greenhouse (Job Board API, docs):

GET https://boards-api.greenhouse.io/v1/boards/{board}/jobs?content=true

Returns {"jobs": [...], "meta": {"total": N}}. Each job has id, title, location.name, absolute_url, updated_at, first_published and, with content=true, an HTML-escaped description in content. Drop content=true if you only need titles; the response gets much smaller.

Lever (Postings API, docs):

GET https://api.lever.co/v0/postings/{site}?mode=json

Returns a bare JSON array. Useful fields: id, text (the title), categories.location, categories.team, categories.commitment, workplaceType, hostedUrl, createdAt (epoch milliseconds). Companies on Lever's EU instance use api.eu.lever.co instead. An unknown site returns {"ok": false, "error": "Document not found"} with a 404, so check for a list before iterating.

Ashby (public job posting API, docs):

GET https://api.ashbyhq.com/posting-api/job-board/{board}?includeCompensation=true

Returns {"jobs": [...]}. Fields: id, title, department, team, location, secondaryLocations, isRemote, workplaceType, employmentType, publishedAt, jobUrl, applyUrl. With includeCompensation=true, many jobs carry compensation.compensationTierSummary, a ready-to-display string such as $211.4K – $290.6K • Offers Equity. Salary data is the main reason I reach for Ashby boards first.

3. One reader for all three

Standard library only:

import json
import urllib.request

UA = {"User-Agent": "job-board-reader/1.0 (+you@example.com)"}


def get_json(url):
    req = urllib.request.Request(url, headers=UA)
    with urllib.request.urlopen(req, timeout=20) as r:
        return json.load(r)


def greenhouse(board):
    data = get_json(f"https://boards-api.greenhouse.io/v1/boards/{board}/jobs?content=true")
    for j in data["jobs"]:
        yield {
            "source": "greenhouse", "id": str(j["id"]), "title": j["title"],
            "location": (j.get("location") or {}).get("name"),
            "posted": j.get("first_published") or j.get("updated_at"),
            "url": j["absolute_url"],
        }


def lever(site):
    for j in get_json(f"https://api.lever.co/v0/postings/{site}?mode=json"):
        cats = j.get("categories") or {}
        yield {
            "source": "lever", "id": j["id"], "title": j["text"],
            "location": cats.get("location"),
            "posted": j.get("createdAt"),  # epoch milliseconds
            "url": j["hostedUrl"],
        }


def ashby(board):
    data = get_json(f"https://api.ashbyhq.com/posting-api/job-board/{board}?includeCompensation=true")
    for j in data["jobs"]:
        yield {
            "source": "ashby", "id": j["id"], "title": j["title"],
            "location": j.get("location"),
            "posted": j.get("publishedAt"),
            "url": j["jobUrl"],
        }


if __name__ == "__main__":
    jobs = [*greenhouse("airbnb"), *lever("spotify"), *ashby("ramp")]
    print(len(jobs), "jobs")

When I ran it, it printed 456 jobs (195 Greenhouse, 89 Lever, 172 Ashby), in under a second end to end.

4. Things that bite

Dates come in three formats. Greenhouse uses ISO 8601 with a local offset, Ashby uses ISO 8601 in UTC, and Lever uses epoch milliseconds. Normalize before you sort or filter by "posted in the last N days".
Greenhouse updated_at is not the posting date. It changes when a recruiter edits the job. Prefer first_published when it is present.
Locations are free text. "Remote - USA", "United States" and "New York, NY (HQ)" all appear. Ashby's isRemote and Lever's workplaceType are more reliable than parsing strings.
IDs are only unique per ATS. Prefix them (ashby:<id>) before you dedupe across sources.
Descriptions are HTML. Greenhouse's is HTML-escaped HTML, so unescape first, then strip tags.
Detecting new jobs is just a set difference: store the prefixed IDs you have seen, and on the next run keep only IDs you have not seen.

5. Be a polite client

These endpoints exist so career pages can render, and that is the reason they are open. Treat them that way:

Send a descriptive User-Agent with a contact address.
Check robots.txt. On the day I wrote this, api.lever.co/robots.txt allowed everything with Crawl-delay: 1, and boards-api.greenhouse.io/robots.txt disallowed only /embed/.
One request per board is enough. Each endpoint returns the whole board, so polling once or twice a day covers almost every use case.
Only collect what the company has already published. Do not try to reach application data or anything behind a login.

Workday career sites are the big platform missing from this list. They also serve JSON, but through a per-tenant POST endpoint with pagination and facets, which deserves a post of its own.

This article was created with the help of AI. The endpoints, numbers and code were tested by me before publishing.