fix: remove local filesystem reads from flaunch and zora providers by CarsonRoscoe · Pull Request #1432 · coinbase/agentkit

CarsonRoscoe · 2026-08-11T12:55:38Z

Description

Both providers treated any non-URL image string as a local filesystem path, read it with fs.readFile, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because image is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it.

The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves.

flaunch: image accepts http(s):// URLs or data: URIs
zora: image accepts https:///ipfs:// URIs or data: URIs
Anything else is rejected before any file or network access
Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error
Tool/schema descriptions and READMEs no longer advertise local paths

Callers publishing a local file now pass a data URI:

image: `data:image/png;base64,${fs.readFileSync(p, "base64")}`

Tests

Manually tested and verified

Checklist

A couple of things to include in your PR for completeness:

Added documentation to all relevant README.md files
Added a changelog entry

Both providers treated any non-URL `image` string as a local filesystem path, read it with `fs.readFile`, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because `image` is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it. The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves. - flaunch: `image` accepts `http(s)://` URLs or `data:` URIs - zora: `image` accepts `https://`/`ipfs://` URIs or `data:` URIs - Anything else is rejected before any file or network access - Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error - Tool/schema descriptions and READMEs no longer advertise local paths Callers publishing a local file now pass a data URI: image: `data:image/png;base64,${fs.readFileSync(p, "base64")}` Co-Authored-By: Claude <noreply@anthropic.com>

cb-heimdall · 2026-08-11T12:55:42Z

✅ Heimdall Review Status

Requirement Status More Info

Reviews

✅ 1/1

Denominator calculation

Show calculation

1 if user is bot 0

1 if user is external 0

2 if repo is sensitive 0

From .codeflow.yml 1

Additional review requirements

Show calculation

Max	0

0

From CODEOWNERS 0

Global minimum 0

Max 1

1

1 if commit is unverified 0

Sum 1

Per CONTRIBUTING-TYPESCRIPT.md, breaking changes take a minor bump. Restricting `image` to remote URLs and data URIs breaks callers that currently pass a local file path, so this is not a patch. Also added the data URI migration snippet to the changeset so it lands in the published changelog rather than only in the PR description. Co-Authored-By: Claude <noreply@anthropic.com>

CarsonRoscoe · 2026-08-11T12:55:38Z

Description

Both providers treated any non-URL image string as a local filesystem path, read it with fs.readFile, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because image is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it.

The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves.

flaunch: image accepts http(s):// URLs or data: URIs
zora: image accepts https:///ipfs:// URIs or data: URIs
Anything else is rejected before any file or network access
Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error
Tool/schema descriptions and READMEs no longer advertise local paths

Callers publishing a local file now pass a data URI:

image: `data:image/png;base64,${fs.readFileSync(p, "base64")}`

Tests

Manually tested and verified

Checklist

A couple of things to include in your PR for completeness:

Added documentation to all relevant README.md files
Added a changelog entry

Both providers treated any non-URL `image` string as a local filesystem path, read it with `fs.readFile`, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because `image` is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it. The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves. - flaunch: `image` accepts `http(s)://` URLs or `data:` URIs - zora: `image` accepts `https://`/`ipfs://` URIs or `data:` URIs - Anything else is rejected before any file or network access - Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error - Tool/schema descriptions and READMEs no longer advertise local paths Callers publishing a local file now pass a data URI: image: `data:image/png;base64,${fs.readFileSync(p, "base64")}` Co-Authored-By: Claude <noreply@anthropic.com>

cb-heimdall · 2026-08-11T12:55:42Z

✅ Heimdall Review Status

Requirement Status More Info

Reviews

✅ 1/1

Denominator calculation

Show calculation

1 if user is bot 0

1 if user is external 0

2 if repo is sensitive 0

From .codeflow.yml 1

Additional review requirements

Show calculation

Max	0

0

From CODEOWNERS 0

Global minimum 0

Max 1

1

1 if commit is unverified 0

Sum 1

Per CONTRIBUTING-TYPESCRIPT.md, breaking changes take a minor bump. Restricting `image` to remote URLs and data URIs breaks callers that currently pass a local file path, so this is not a patch. Also added the data URI migration snippet to the changeset so it lands in the published changelog rather than only in the PR description. Co-Authored-By: Claude <noreply@anthropic.com>

CarsonRoscoe · 2026-08-11T12:55:38Z

Description

Both providers treated any non-URL image string as a local filesystem path, read it with fs.readFile, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because image is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it.

The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves.

flaunch: image accepts http(s):// URLs or data: URIs
zora: image accepts https:///ipfs:// URIs or data: URIs
Anything else is rejected before any file or network access
Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error
Tool/schema descriptions and READMEs no longer advertise local paths

Callers publishing a local file now pass a data URI:

image: `data:image/png;base64,${fs.readFileSync(p, "base64")}`

Tests

Manually tested and verified

Checklist

A couple of things to include in your PR for completeness:

Added documentation to all relevant README.md files
Added a changelog entry

Both providers treated any non-URL `image` string as a local filesystem path, read it with `fs.readFile`, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because `image` is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it. The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves. - flaunch: `image` accepts `http(s)://` URLs or `data:` URIs - zora: `image` accepts `https://`/`ipfs://` URIs or `data:` URIs - Anything else is rejected before any file or network access - Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error - Tool/schema descriptions and READMEs no longer advertise local paths Callers publishing a local file now pass a data URI: image: `data:image/png;base64,${fs.readFileSync(p, "base64")}` Co-Authored-By: Claude <noreply@anthropic.com>

cb-heimdall · 2026-08-11T12:55:42Z

✅ Heimdall Review Status

Requirement Status More Info

Reviews

✅ 1/1

Denominator calculation

Show calculation

1 if user is bot 0

1 if user is external 0

2 if repo is sensitive 0

From .codeflow.yml 1

Additional review requirements

Show calculation

Max	0

0

From CODEOWNERS 0

Global minimum 0

Max 1

1

1 if commit is unverified 0

Sum 1

Per CONTRIBUTING-TYPESCRIPT.md, breaking changes take a minor bump. Restricting `image` to remote URLs and data URIs breaks callers that currently pass a local file path, so this is not a patch. Also added the data URI migration snippet to the changeset so it lands in the published changelog rather than only in the PR description. Co-Authored-By: Claude <noreply@anthropic.com>

CarsonRoscoe · 2026-08-11T12:55:38Z

Description

Both providers treated any non-URL image string as a local filesystem path, read it with fs.readFile, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because image is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it.

The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves.

flaunch: image accepts http(s):// URLs or data: URIs
zora: image accepts https:///ipfs:// URIs or data: URIs
Anything else is rejected before any file or network access
Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error
Tool/schema descriptions and READMEs no longer advertise local paths

Callers publishing a local file now pass a data URI:

image: `data:image/png;base64,${fs.readFileSync(p, "base64")}`

Tests

Manually tested and verified

Checklist

A couple of things to include in your PR for completeness:

Added documentation to all relevant README.md files
Added a changelog entry

Both providers treated any non-URL `image` string as a local filesystem path, read it with `fs.readFile`, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because `image` is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it. The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves. - flaunch: `image` accepts `http(s)://` URLs or `data:` URIs - zora: `image` accepts `https://`/`ipfs://` URIs or `data:` URIs - Anything else is rejected before any file or network access - Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error - Tool/schema descriptions and READMEs no longer advertise local paths Callers publishing a local file now pass a data URI: image: `data:image/png;base64,${fs.readFileSync(p, "base64")}` Co-Authored-By: Claude <noreply@anthropic.com>

cb-heimdall · 2026-08-11T12:55:42Z

✅ Heimdall Review Status

Requirement Status More Info

Reviews

✅ 1/1

Denominator calculation

Show calculation

1 if user is bot 0

1 if user is external 0

2 if repo is sensitive 0

From .codeflow.yml 1

Additional review requirements

Show calculation

Max	0

0

From CODEOWNERS 0

Global minimum 0

Max 1

1

1 if commit is unverified 0

Sum 1

Per CONTRIBUTING-TYPESCRIPT.md, breaking changes take a minor bump. Restricting `image` to remote URLs and data URIs breaks callers that currently pass a local file path, so this is not a patch. Also added the data URI migration snippet to the changeset so it lands in the published changelog rather than only in the PR description. Co-Authored-By: Claude <noreply@anthropic.com>

CarsonRoscoe · 2026-08-11T12:55:38Z

Description

Both providers treated any non-URL image string as a local filesystem path, read it with fs.readFile, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because image is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it.

The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves.

flaunch: image accepts http(s):// URLs or data: URIs
zora: image accepts https:///ipfs:// URIs or data: URIs
Anything else is rejected before any file or network access
Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error
Tool/schema descriptions and READMEs no longer advertise local paths

Callers publishing a local file now pass a data URI:

image: `data:image/png;base64,${fs.readFileSync(p, "base64")}`

Tests

Manually tested and verified

Checklist

A couple of things to include in your PR for completeness:

Added documentation to all relevant README.md files
Added a changelog entry

Both providers treated any non-URL `image` string as a local filesystem path, read it with `fs.readFile`, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because `image` is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it. The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves. - flaunch: `image` accepts `http(s)://` URLs or `data:` URIs - zora: `image` accepts `https://`/`ipfs://` URIs or `data:` URIs - Anything else is rejected before any file or network access - Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error - Tool/schema descriptions and READMEs no longer advertise local paths Callers publishing a local file now pass a data URI: image: `data:image/png;base64,${fs.readFileSync(p, "base64")}` Co-Authored-By: Claude <noreply@anthropic.com>

cb-heimdall · 2026-08-11T12:55:42Z

✅ Heimdall Review Status

Requirement Status More Info

Reviews

✅ 1/1

Denominator calculation

Show calculation

1 if user is bot 0

1 if user is external 0

2 if repo is sensitive 0

From .codeflow.yml 1

Additional review requirements

Show calculation

Max	0

0

From CODEOWNERS 0

Global minimum 0

Max 1

1

1 if commit is unverified 0

Sum 1

Per CONTRIBUTING-TYPESCRIPT.md, breaking changes take a minor bump. Restricting `image` to remote URLs and data URIs breaks callers that currently pass a local file path, so this is not a patch. Also added the data URI migration snippet to the changeset so it lands in the published changelog rather than only in the PR description. Co-Authored-By: Claude <noreply@anthropic.com>

CarsonRoscoe · 2026-08-11T12:55:38Z

Description

Both providers treated any non-URL image string as a local filesystem path, read it with fs.readFile, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because image is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it.

The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves.

flaunch: image accepts http(s):// URLs or data: URIs
zora: image accepts https:///ipfs:// URIs or data: URIs
Anything else is rejected before any file or network access
Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error
Tool/schema descriptions and READMEs no longer advertise local paths

Callers publishing a local file now pass a data URI:

image: `data:image/png;base64,${fs.readFileSync(p, "base64")}`

Tests

Manually tested and verified

Checklist

A couple of things to include in your PR for completeness:

Added documentation to all relevant README.md files
Added a changelog entry

Both providers treated any non-URL `image` string as a local filesystem path, read it with `fs.readFile`, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because `image` is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it. The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves. - flaunch: `image` accepts `http(s)://` URLs or `data:` URIs - zora: `image` accepts `https://`/`ipfs://` URIs or `data:` URIs - Anything else is rejected before any file or network access - Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error - Tool/schema descriptions and READMEs no longer advertise local paths Callers publishing a local file now pass a data URI: image: `data:image/png;base64,${fs.readFileSync(p, "base64")}` Co-Authored-By: Claude <noreply@anthropic.com>

cb-heimdall · 2026-08-11T12:55:42Z

✅ Heimdall Review Status

Requirement Status More Info

Reviews

✅ 1/1

Denominator calculation

Show calculation

1 if user is bot 0

1 if user is external 0

2 if repo is sensitive 0

From .codeflow.yml 1

Additional review requirements

Show calculation

Max	0

0

From CODEOWNERS 0

Global minimum 0

Max 1

1

1 if commit is unverified 0

Sum 1

Per CONTRIBUTING-TYPESCRIPT.md, breaking changes take a minor bump. Restricting `image` to remote URLs and data URIs breaks callers that currently pass a local file path, so this is not a patch. Also added the data URI migration snippet to the changeset so it lands in the published changelog rather than only in the PR description. Co-Authored-By: Claude <noreply@anthropic.com>

CarsonRoscoe · 2026-08-11T12:55:38Z

Description

Both providers treated any non-URL image string as a local filesystem path, read it with fs.readFile, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because image is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it.

The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves.

flaunch: image accepts http(s):// URLs or data: URIs
zora: image accepts https:///ipfs:// URIs or data: URIs
Anything else is rejected before any file or network access
Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error
Tool/schema descriptions and READMEs no longer advertise local paths

Callers publishing a local file now pass a data URI:

image: `data:image/png;base64,${fs.readFileSync(p, "base64")}`

Tests

Manually tested and verified

Checklist

A couple of things to include in your PR for completeness:

Added documentation to all relevant README.md files
Added a changelog entry

Both providers treated any non-URL `image` string as a local filesystem path, read it with `fs.readFile`, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because `image` is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it. The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves. - flaunch: `image` accepts `http(s)://` URLs or `data:` URIs - zora: `image` accepts `https://`/`ipfs://` URIs or `data:` URIs - Anything else is rejected before any file or network access - Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error - Tool/schema descriptions and READMEs no longer advertise local paths Callers publishing a local file now pass a data URI: image: `data:image/png;base64,${fs.readFileSync(p, "base64")}` Co-Authored-By: Claude <noreply@anthropic.com>

cb-heimdall · 2026-08-11T12:55:42Z

✅ Heimdall Review Status

Requirement Status More Info

Reviews

✅ 1/1

Denominator calculation

Show calculation

1 if user is bot 0

1 if user is external 0

2 if repo is sensitive 0

From .codeflow.yml 1

Additional review requirements

Show calculation

Max	0

0

From CODEOWNERS 0

Global minimum 0

Max 1

1

1 if commit is unverified 0

Sum 1

Per CONTRIBUTING-TYPESCRIPT.md, breaking changes take a minor bump. Restricting `image` to remote URLs and data URIs breaks callers that currently pass a local file path, so this is not a patch. Also added the data URI migration snippet to the changeset so it lands in the published changelog rather than only in the PR description. Co-Authored-By: Claude <noreply@anthropic.com>

CarsonRoscoe · 2026-08-11T12:55:38Z

Description

Both providers treated any non-URL image string as a local filesystem path, read it with fs.readFile, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because image is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it.

The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves.

flaunch: image accepts http(s):// URLs or data: URIs
zora: image accepts https:///ipfs:// URIs or data: URIs
Anything else is rejected before any file or network access
Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error
Tool/schema descriptions and READMEs no longer advertise local paths

Callers publishing a local file now pass a data URI:

image: `data:image/png;base64,${fs.readFileSync(p, "base64")}`

Tests

Manually tested and verified

Checklist

A couple of things to include in your PR for completeness:

Added documentation to all relevant README.md files
Added a changelog entry

Both providers treated any non-URL `image` string as a local filesystem path, read it with `fs.readFile`, and uploaded the bytes to a third-party IPFS pinning service (web2-api.flaunch.gg and Pinata respectively), which pins them publicly. Because `image` is an LLM-supplied tool argument whose description explicitly advertised "Local image file path", an agent could be induced to read an arbitrary file off the host and publish it. The local-file affordance is not useful to an agent, which has no knowledge of the host filesystem. It only ever served direct programmatic SDK callers, who can perform the read themselves. - flaunch: `image` accepts `http(s)://` URLs or `data:` URIs - zora: `image` accepts `https://`/`ipfs://` URIs or `data:` URIs - Anything else is rejected before any file or network access - Zod schemas reject non-URL values, so the constraint is also visible to the model rather than surfacing only as a runtime error - Tool/schema descriptions and READMEs no longer advertise local paths Callers publishing a local file now pass a data URI: image: `data:image/png;base64,${fs.readFileSync(p, "base64")}` Co-Authored-By: Claude <noreply@anthropic.com>

cb-heimdall · 2026-08-11T12:55:42Z

✅ Heimdall Review Status

Requirement Status More Info

Reviews

✅ 1/1

Denominator calculation

Show calculation

1 if user is bot 0

1 if user is external 0

2 if repo is sensitive 0

From .codeflow.yml 1

Additional review requirements

Show calculation

Max	0

0

From CODEOWNERS 0

Global minimum 0

Max 1

1

1 if commit is unverified 0

Sum 1

Per CONTRIBUTING-TYPESCRIPT.md, breaking changes take a minor bump. Restricting `image` to remote URLs and data URIs breaks callers that currently pass a local file path, so this is not a patch. Also added the data URI migration snippet to the changeset so it lands in the published changelog rather than only in the PR description. Co-Authored-By: Claude <noreply@anthropic.com>

CarsonRoscoe requested a review from murrlincoln as a code owner August 11, 2026 12:55

github-actionsBot added documentation Improvements or additions to documentation action provider New action provider typescript labels Aug 11, 2026

fix: unit tests
0a86c67

phdargen self-assigned this Aug 19, 2026

phdargen approved these changes Aug 19, 2026
View reviewed changes

phdargen merged commit 455a6c5 into mainAug 19, 2026
31 checks passed

phdargen deleted the fix/remove-local-file-reads-flaunch-zora branch August 19, 2026 19:00

github-actionsBot mentioned this pull request Aug 19, 2026
chore: version typescript packages #745
Open

CarsonRoscoe requested a review from murrlincoln as a code owner August 11, 2026 12:55

github-actionsBot added documentation Improvements or additions to documentation action provider New action provider typescript labels Aug 11, 2026

fix: unit tests
0a86c67

phdargen self-assigned this Aug 19, 2026

phdargen approved these changes Aug 19, 2026
View reviewed changes

phdargen merged commit 455a6c5 into mainAug 19, 2026
31 checks passed

phdargen deleted the fix/remove-local-file-reads-flaunch-zora branch August 19, 2026 19:00

github-actionsBot mentioned this pull request Aug 19, 2026
chore: version typescript packages #745
Open

CarsonRoscoe requested a review from murrlincoln as a code owner August 11, 2026 12:55

github-actionsBot added documentation Improvements or additions to documentation action provider New action provider typescript labels Aug 11, 2026

fix: unit tests
0a86c67

phdargen self-assigned this Aug 19, 2026

phdargen approved these changes Aug 19, 2026
View reviewed changes

phdargen merged commit 455a6c5 into mainAug 19, 2026
31 checks passed

phdargen deleted the fix/remove-local-file-reads-flaunch-zora branch August 19, 2026 19:00

github-actionsBot mentioned this pull request Aug 19, 2026
chore: version typescript packages #745
Open

CarsonRoscoe requested a review from murrlincoln as a code owner August 11, 2026 12:55

github-actionsBot added documentation Improvements or additions to documentation action provider New action provider typescript labels Aug 11, 2026

fix: unit tests
0a86c67

phdargen self-assigned this Aug 19, 2026

phdargen approved these changes Aug 19, 2026
View reviewed changes

phdargen merged commit 455a6c5 into mainAug 19, 2026
31 checks passed

phdargen deleted the fix/remove-local-file-reads-flaunch-zora branch August 19, 2026 19:00

github-actionsBot mentioned this pull request Aug 19, 2026
chore: version typescript packages #745
Open

CarsonRoscoe requested a review from murrlincoln as a code owner August 11, 2026 12:55

github-actionsBot added documentation Improvements or additions to documentation action provider New action provider typescript labels Aug 11, 2026

fix: unit tests
0a86c67

phdargen self-assigned this Aug 19, 2026

phdargen approved these changes Aug 19, 2026
View reviewed changes

phdargen merged commit 455a6c5 into mainAug 19, 2026
31 checks passed

phdargen deleted the fix/remove-local-file-reads-flaunch-zora branch August 19, 2026 19:00

github-actionsBot mentioned this pull request Aug 19, 2026
chore: version typescript packages #745
Open

CarsonRoscoe requested a review from murrlincoln as a code owner August 11, 2026 12:55

github-actionsBot added documentation Improvements or additions to documentation action provider New action provider typescript labels Aug 11, 2026

fix: unit tests
0a86c67

phdargen self-assigned this Aug 19, 2026

phdargen approved these changes Aug 19, 2026
View reviewed changes

phdargen merged commit 455a6c5 into mainAug 19, 2026
31 checks passed

phdargen deleted the fix/remove-local-file-reads-flaunch-zora branch August 19, 2026 19:00

github-actionsBot mentioned this pull request Aug 19, 2026
chore: version typescript packages #745
Open

CarsonRoscoe requested a review from murrlincoln as a code owner August 11, 2026 12:55

github-actionsBot added documentation Improvements or additions to documentation action provider New action provider typescript labels Aug 11, 2026

fix: unit tests
0a86c67

phdargen self-assigned this Aug 19, 2026

phdargen approved these changes Aug 19, 2026
View reviewed changes

phdargen merged commit 455a6c5 into mainAug 19, 2026
31 checks passed

phdargen deleted the fix/remove-local-file-reads-flaunch-zora branch August 19, 2026 19:00

github-actionsBot mentioned this pull request Aug 19, 2026
chore: version typescript packages #745
Open

CarsonRoscoe requested a review from murrlincoln as a code owner August 11, 2026 12:55

github-actionsBot added documentation Improvements or additions to documentation action provider New action provider typescript labels Aug 11, 2026

fix: unit tests
0a86c67

phdargen self-assigned this Aug 19, 2026

phdargen approved these changes Aug 19, 2026
View reviewed changes

phdargen merged commit 455a6c5 into mainAug 19, 2026
31 checks passed

phdargen deleted the fix/remove-local-file-reads-flaunch-zora branch August 19, 2026 19:00

github-actionsBot mentioned this pull request Aug 19, 2026
chore: version typescript packages #745
Open

Uh oh!

Conversation

CarsonRoscoe commented Aug 11, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Tests

Checklist

Uh oh!

cb-heimdall commented Aug 11, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Heimdall Review Status

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

CarsonRoscoe commented Aug 11, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Tests

Checklist

Uh oh!

cb-heimdall commented Aug 11, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Heimdall Review Status

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

CarsonRoscoe commented Aug 11, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Tests

Checklist

Uh oh!

cb-heimdall commented Aug 11, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Heimdall Review Status

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

CarsonRoscoe commented Aug 11, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Tests

Checklist

Uh oh!

cb-heimdall commented Aug 11, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Heimdall Review Status

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

CarsonRoscoe commented Aug 11, 2026•
edited
Loading

cb-heimdall commented Aug 11, 2026•
edited
Loading

CarsonRoscoe commented Aug 11, 2026•
edited
Loading

cb-heimdall commented Aug 11, 2026•
edited
Loading

CarsonRoscoe commented Aug 11, 2026•
edited
Loading

cb-heimdall commented Aug 11, 2026•
edited
Loading

CarsonRoscoe commented Aug 11, 2026•
edited
Loading

cb-heimdall commented Aug 11, 2026•
edited
Loading

CarsonRoscoe commented Aug 11, 2026•
edited
Loading

cb-heimdall commented Aug 11, 2026•
edited
Loading

CarsonRoscoe commented Aug 11, 2026•
edited
Loading

cb-heimdall commented Aug 11, 2026•
edited
Loading