[anandghegde]

Description

• Adds a zod file icon based on the Zod logo: the gem outline with the "Z" cut out, simplified so it stays readable at 16px. Drawn on the 16x16 grid with whole-number coordinates.
• Uses a single colour, #448aff (blue A200), which is the closest palette match to Zod's blue and is different enough from the TypeScript icon. Because the Z is a cut-out, the icon works on both light and dark themes without a _light variant.
• Maps *.zod.ts and *.z.ts to the icon, as requested in the issue.

npm run check, npm run check-colors, npm test and npm run build all pass locally.

Closes #3552

Contribution Guidelines

• By creating this pull request, I acknowledge that I have read the Contribution Guidelines for this project
• I have read the Code Of Conduct and promise to abide by these rules

[anandghegde]

The red Icon Review check here is a workflow issue rather than anything in this PR — it never gets as far as looking at the icon.

##[error]Refusing to check out fork pull request code from a 'pull_request_target' workflow.
This workflow runs with the base repository's GITHUB_TOKEN, secrets, default-branch cache
scope, and runner access. ... To opt in, review the risks at
https://gh.io/securely-using-pull_request_target and set 'allow-unsafe-pr-checkout: true'
on the actions/checkout step.

The job fails at the actions/checkout step that fetches the fork ref into fork/, before any icon is rendered.

It looks like recent actions/checkout hardening rather than a change on this branch:

PR	Icon Review ran	Result
#3579	2026-09-05	✅
#3580	2026-09-05	✅
#3581	2026-09-04	✅
#3589 (this)	2026-09-13	❌

So any fork PR touching icons/ should now hit this.

Two ways out, and the choice is a security one for you rather than me: set allow-unsafe-pr-checkout: true on that step (the sparse checkout is limited to icons/, so it pulls SVG data rather than executable code, but it does run in the trusted pull_request_target context), or split the render step into a pull_request workflow that has no secrets and let pull_request_target only post the comment.

Happy to open a PR for whichever you prefer — just say which. The icon itself is unchanged and fileIcons.ts is wired up as usual.

[anandghegde]

Heads up that the red Icon Review here isn't about the icon — the job dies in ~5s before it ever looks at the SVG:

##[error]Refusing to check out fork pull request code from a 'pull_request_target' workflow.
... set 'allow-unsafe-pr-checkout: true' on the actions/checkout step.

actions/checkout v7 started refusing to check out a fork ref under pull_request_target, and .github/workflows/icon-review.yml does exactly that in its 📥 Checkout Fork step. It's repo-wide, not specific to this PR:

PR	Icon Review	run date
#3581	pass (19s)	2026-09-04
#3589 (this one)	fail (7s)	2026-09-13
#3591	fail (4s)	2026-09-16
#3593	fail (5s)	2026-09-19

Same error text on #3591 and #3593. So every fork PR that touches icons/*.svg is currently red.

Two ways out, for whenever a maintainer gets to it:

• One-line unblock — add allow-unsafe-pr-checkout: true to the Checkout Fork step. The checkout is already sparse-checkout: icons/, so no fork workflow or script files land on disk. Worth noting it isn't zero-risk though: svg-icon-review renders those SVGs in a headless browser with --noSandbox, in a job that has secrets.IMAGE_UPLOAD in its environment.
• Split the job — render the preview in an unprivileged pull_request workflow and upload preview.png as an artifact, then do the freeimage upload and the PR comment from a workflow_run job that holds the secret but never touches fork content. More work, but the untrusted SVGs and the secret never share a runner. (A third option: skip the fork checkout entirely and pull the changed SVGs from the PR files API, since icons/ is all the job needs.)

Happy to send either as its own PR if that's useful — just say which you'd prefer.

[github-actions]

Preview

Thank you for creating a pull request. This preview shows you how your icon will look on the different themes:

Check how your icon fits in a 16x16 grid with our Pixel Perfect Checker by following this link.

You can find more information on how to contribute in the contribution guidelines.