fix(publish): pass multipart JSON via files, not inline -F values by tastybento · Pull Request #13 · BentoBoxWorld/.github

tastybento · 2026-07-20T01:22:05Z

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them — every HTML entity does — truncated the JSON part of the multipart upload, so CurseForge rejected metadata as invalid JSON (error 1002) and Hangar failed to read the request (HTTP 400). Seen on the AcidIsland 2.0.0 release: https://github.com/BentoBoxWorld/AcidIsland/actions/runs/29710523349

The <file form reads the part content out-of-band, so the payload can contain any characters. Validated by re-running the AcidIsland 2.0.0 publish pinned to this branch's SHA.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them - every HTML entity does - truncated the JSON part, so CurseForge rejected metadata as invalid JSON and Hangar failed to read the request. The <file form reads content out-of-band and is immune to the payload's characters. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

The pinned SHA predates BentoBoxWorld/.github#13, which moved the CurseForge metadata and Hangar versionUpload JSON out of inline curl -F values and into files. curl treats a ';' in an inline -F value as the start of a type= attribute, so a release body containing a semicolon truncates the JSON and both platforms reject the upload. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

## What Bumps the pinned SHA of the shared `publish-platforms.yml` reusable workflow to `1f91a0e` (master HEAD of `BentoBoxWorld/.github`). ## Why The pinned version passes the CurseForge `metadata` and Hangar `versionUpload` multipart JSON as an inline curl value: ``` -F "metadata=${META};type=application/json" ``` curl reads a `;` inside an inline `-F` value as the start of a `type=`/`filename=` attribute, so the JSON is silently truncated at the first semicolon in the release body. Both platforms then reject the upload: - CurseForge — `{"errorCode":1002,"errorMessage":"Error in field \`metadata\`: Invalid JSON."}` - Hangar — `{"status":400,"detail":"Failed to read request"}` This is latent, not theoretical: it took down the AOneBlock 1.26.3 publish ([run](https://github.com/BentoBoxWorld/AOneBlock/actions/runs/30468254213)) because those release notes happened to contain one semicolon. Any release body with a semicolon in it trips this. BentoBoxWorld/.github#13 fixed it on 2026-07-20 by writing the JSON to a file and using curl's `<file` form (`-F "metadata=<cf_meta.json;type=application/json"`). This repo was still pinned to the commit before that fix. Modrinth publishing is unaffected — it does not go through this workflow. No behaviour change beyond the fix; the pin is the only line touched. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

tastybento · 2026-07-20T01:22:05Z

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them — every HTML entity does — truncated the JSON part of the multipart upload, so CurseForge rejected metadata as invalid JSON (error 1002) and Hangar failed to read the request (HTTP 400). Seen on the AcidIsland 2.0.0 release: https://github.com/BentoBoxWorld/AcidIsland/actions/runs/29710523349

The <file form reads the part content out-of-band, so the payload can contain any characters. Validated by re-running the AcidIsland 2.0.0 publish pinned to this branch's SHA.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them - every HTML entity does - truncated the JSON part, so CurseForge rejected metadata as invalid JSON and Hangar failed to read the request. The <file form reads content out-of-band and is immune to the payload's characters. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

The pinned SHA predates BentoBoxWorld/.github#13, which moved the CurseForge metadata and Hangar versionUpload JSON out of inline curl -F values and into files. curl treats a ';' in an inline -F value as the start of a type= attribute, so a release body containing a semicolon truncates the JSON and both platforms reject the upload. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

## What Bumps the pinned SHA of the shared `publish-platforms.yml` reusable workflow to `1f91a0e` (master HEAD of `BentoBoxWorld/.github`). ## Why The pinned version passes the CurseForge `metadata` and Hangar `versionUpload` multipart JSON as an inline curl value: ``` -F "metadata=${META};type=application/json" ``` curl reads a `;` inside an inline `-F` value as the start of a `type=`/`filename=` attribute, so the JSON is silently truncated at the first semicolon in the release body. Both platforms then reject the upload: - CurseForge — `{"errorCode":1002,"errorMessage":"Error in field \`metadata\`: Invalid JSON."}` - Hangar — `{"status":400,"detail":"Failed to read request"}` This is latent, not theoretical: it took down the AOneBlock 1.26.3 publish ([run](https://github.com/BentoBoxWorld/AOneBlock/actions/runs/30468254213)) because those release notes happened to contain one semicolon. Any release body with a semicolon in it trips this. BentoBoxWorld/.github#13 fixed it on 2026-07-20 by writing the JSON to a file and using curl's `<file` form (`-F "metadata=<cf_meta.json;type=application/json"`). This repo was still pinned to the commit before that fix. Modrinth publishing is unaffected — it does not go through this workflow. No behaviour change beyond the fix; the pin is the only line touched. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

tastybento · 2026-07-20T01:22:05Z

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them — every HTML entity does — truncated the JSON part of the multipart upload, so CurseForge rejected metadata as invalid JSON (error 1002) and Hangar failed to read the request (HTTP 400). Seen on the AcidIsland 2.0.0 release: https://github.com/BentoBoxWorld/AcidIsland/actions/runs/29710523349

The <file form reads the part content out-of-band, so the payload can contain any characters. Validated by re-running the AcidIsland 2.0.0 publish pinned to this branch's SHA.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them - every HTML entity does - truncated the JSON part, so CurseForge rejected metadata as invalid JSON and Hangar failed to read the request. The <file form reads content out-of-band and is immune to the payload's characters. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

The pinned SHA predates BentoBoxWorld/.github#13, which moved the CurseForge metadata and Hangar versionUpload JSON out of inline curl -F values and into files. curl treats a ';' in an inline -F value as the start of a type= attribute, so a release body containing a semicolon truncates the JSON and both platforms reject the upload. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

## What Bumps the pinned SHA of the shared `publish-platforms.yml` reusable workflow to `1f91a0e` (master HEAD of `BentoBoxWorld/.github`). ## Why The pinned version passes the CurseForge `metadata` and Hangar `versionUpload` multipart JSON as an inline curl value: ``` -F "metadata=${META};type=application/json" ``` curl reads a `;` inside an inline `-F` value as the start of a `type=`/`filename=` attribute, so the JSON is silently truncated at the first semicolon in the release body. Both platforms then reject the upload: - CurseForge — `{"errorCode":1002,"errorMessage":"Error in field \`metadata\`: Invalid JSON."}` - Hangar — `{"status":400,"detail":"Failed to read request"}` This is latent, not theoretical: it took down the AOneBlock 1.26.3 publish ([run](https://github.com/BentoBoxWorld/AOneBlock/actions/runs/30468254213)) because those release notes happened to contain one semicolon. Any release body with a semicolon in it trips this. BentoBoxWorld/.github#13 fixed it on 2026-07-20 by writing the JSON to a file and using curl's `<file` form (`-F "metadata=<cf_meta.json;type=application/json"`). This repo was still pinned to the commit before that fix. Modrinth publishing is unaffected — it does not go through this workflow. No behaviour change beyond the fix; the pin is the only line touched. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

tastybento · 2026-07-20T01:22:05Z

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them — every HTML entity does — truncated the JSON part of the multipart upload, so CurseForge rejected metadata as invalid JSON (error 1002) and Hangar failed to read the request (HTTP 400). Seen on the AcidIsland 2.0.0 release: https://github.com/BentoBoxWorld/AcidIsland/actions/runs/29710523349

The <file form reads the part content out-of-band, so the payload can contain any characters. Validated by re-running the AcidIsland 2.0.0 publish pinned to this branch's SHA.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them - every HTML entity does - truncated the JSON part, so CurseForge rejected metadata as invalid JSON and Hangar failed to read the request. The <file form reads content out-of-band and is immune to the payload's characters. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

The pinned SHA predates BentoBoxWorld/.github#13, which moved the CurseForge metadata and Hangar versionUpload JSON out of inline curl -F values and into files. curl treats a ';' in an inline -F value as the start of a type= attribute, so a release body containing a semicolon truncates the JSON and both platforms reject the upload. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

## What Bumps the pinned SHA of the shared `publish-platforms.yml` reusable workflow to `1f91a0e` (master HEAD of `BentoBoxWorld/.github`). ## Why The pinned version passes the CurseForge `metadata` and Hangar `versionUpload` multipart JSON as an inline curl value: ``` -F "metadata=${META};type=application/json" ``` curl reads a `;` inside an inline `-F` value as the start of a `type=`/`filename=` attribute, so the JSON is silently truncated at the first semicolon in the release body. Both platforms then reject the upload: - CurseForge — `{"errorCode":1002,"errorMessage":"Error in field \`metadata\`: Invalid JSON."}` - Hangar — `{"status":400,"detail":"Failed to read request"}` This is latent, not theoretical: it took down the AOneBlock 1.26.3 publish ([run](https://github.com/BentoBoxWorld/AOneBlock/actions/runs/30468254213)) because those release notes happened to contain one semicolon. Any release body with a semicolon in it trips this. BentoBoxWorld/.github#13 fixed it on 2026-07-20 by writing the JSON to a file and using curl's `<file` form (`-F "metadata=<cf_meta.json;type=application/json"`). This repo was still pinned to the commit before that fix. Modrinth publishing is unaffected — it does not go through this workflow. No behaviour change beyond the fix; the pin is the only line touched. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

tastybento · 2026-07-20T01:22:05Z

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them — every HTML entity does — truncated the JSON part of the multipart upload, so CurseForge rejected metadata as invalid JSON (error 1002) and Hangar failed to read the request (HTTP 400). Seen on the AcidIsland 2.0.0 release: https://github.com/BentoBoxWorld/AcidIsland/actions/runs/29710523349

The <file form reads the part content out-of-band, so the payload can contain any characters. Validated by re-running the AcidIsland 2.0.0 publish pinned to this branch's SHA.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them - every HTML entity does - truncated the JSON part, so CurseForge rejected metadata as invalid JSON and Hangar failed to read the request. The <file form reads content out-of-band and is immune to the payload's characters. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

The pinned SHA predates BentoBoxWorld/.github#13, which moved the CurseForge metadata and Hangar versionUpload JSON out of inline curl -F values and into files. curl treats a ';' in an inline -F value as the start of a type= attribute, so a release body containing a semicolon truncates the JSON and both platforms reject the upload. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

## What Bumps the pinned SHA of the shared `publish-platforms.yml` reusable workflow to `1f91a0e` (master HEAD of `BentoBoxWorld/.github`). ## Why The pinned version passes the CurseForge `metadata` and Hangar `versionUpload` multipart JSON as an inline curl value: ``` -F "metadata=${META};type=application/json" ``` curl reads a `;` inside an inline `-F` value as the start of a `type=`/`filename=` attribute, so the JSON is silently truncated at the first semicolon in the release body. Both platforms then reject the upload: - CurseForge — `{"errorCode":1002,"errorMessage":"Error in field \`metadata\`: Invalid JSON."}` - Hangar — `{"status":400,"detail":"Failed to read request"}` This is latent, not theoretical: it took down the AOneBlock 1.26.3 publish ([run](https://github.com/BentoBoxWorld/AOneBlock/actions/runs/30468254213)) because those release notes happened to contain one semicolon. Any release body with a semicolon in it trips this. BentoBoxWorld/.github#13 fixed it on 2026-07-20 by writing the JSON to a file and using curl's `<file` form (`-F "metadata=<cf_meta.json;type=application/json"`). This repo was still pinned to the commit before that fix. Modrinth publishing is unaffected — it does not go through this workflow. No behaviour change beyond the fix; the pin is the only line touched. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

tastybento · 2026-07-20T01:22:05Z

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them — every HTML entity does — truncated the JSON part of the multipart upload, so CurseForge rejected metadata as invalid JSON (error 1002) and Hangar failed to read the request (HTTP 400). Seen on the AcidIsland 2.0.0 release: https://github.com/BentoBoxWorld/AcidIsland/actions/runs/29710523349

The <file form reads the part content out-of-band, so the payload can contain any characters. Validated by re-running the AcidIsland 2.0.0 publish pinned to this branch's SHA.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them - every HTML entity does - truncated the JSON part, so CurseForge rejected metadata as invalid JSON and Hangar failed to read the request. The <file form reads content out-of-band and is immune to the payload's characters. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

The pinned SHA predates BentoBoxWorld/.github#13, which moved the CurseForge metadata and Hangar versionUpload JSON out of inline curl -F values and into files. curl treats a ';' in an inline -F value as the start of a type= attribute, so a release body containing a semicolon truncates the JSON and both platforms reject the upload. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

## What Bumps the pinned SHA of the shared `publish-platforms.yml` reusable workflow to `1f91a0e` (master HEAD of `BentoBoxWorld/.github`). ## Why The pinned version passes the CurseForge `metadata` and Hangar `versionUpload` multipart JSON as an inline curl value: ``` -F "metadata=${META};type=application/json" ``` curl reads a `;` inside an inline `-F` value as the start of a `type=`/`filename=` attribute, so the JSON is silently truncated at the first semicolon in the release body. Both platforms then reject the upload: - CurseForge — `{"errorCode":1002,"errorMessage":"Error in field \`metadata\`: Invalid JSON."}` - Hangar — `{"status":400,"detail":"Failed to read request"}` This is latent, not theoretical: it took down the AOneBlock 1.26.3 publish ([run](https://github.com/BentoBoxWorld/AOneBlock/actions/runs/30468254213)) because those release notes happened to contain one semicolon. Any release body with a semicolon in it trips this. BentoBoxWorld/.github#13 fixed it on 2026-07-20 by writing the JSON to a file and using curl's `<file` form (`-F "metadata=<cf_meta.json;type=application/json"`). This repo was still pinned to the commit before that fix. Modrinth publishing is unaffected — it does not go through this workflow. No behaviour change beyond the fix; the pin is the only line touched. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

tastybento · 2026-07-20T01:22:05Z

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them — every HTML entity does — truncated the JSON part of the multipart upload, so CurseForge rejected metadata as invalid JSON (error 1002) and Hangar failed to read the request (HTTP 400). Seen on the AcidIsland 2.0.0 release: https://github.com/BentoBoxWorld/AcidIsland/actions/runs/29710523349

The <file form reads the part content out-of-band, so the payload can contain any characters. Validated by re-running the AcidIsland 2.0.0 publish pinned to this branch's SHA.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them - every HTML entity does - truncated the JSON part, so CurseForge rejected metadata as invalid JSON and Hangar failed to read the request. The <file form reads content out-of-band and is immune to the payload's characters. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

The pinned SHA predates BentoBoxWorld/.github#13, which moved the CurseForge metadata and Hangar versionUpload JSON out of inline curl -F values and into files. curl treats a ';' in an inline -F value as the start of a type= attribute, so a release body containing a semicolon truncates the JSON and both platforms reject the upload. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

## What Bumps the pinned SHA of the shared `publish-platforms.yml` reusable workflow to `1f91a0e` (master HEAD of `BentoBoxWorld/.github`). ## Why The pinned version passes the CurseForge `metadata` and Hangar `versionUpload` multipart JSON as an inline curl value: ``` -F "metadata=${META};type=application/json" ``` curl reads a `;` inside an inline `-F` value as the start of a `type=`/`filename=` attribute, so the JSON is silently truncated at the first semicolon in the release body. Both platforms then reject the upload: - CurseForge — `{"errorCode":1002,"errorMessage":"Error in field \`metadata\`: Invalid JSON."}` - Hangar — `{"status":400,"detail":"Failed to read request"}` This is latent, not theoretical: it took down the AOneBlock 1.26.3 publish ([run](https://github.com/BentoBoxWorld/AOneBlock/actions/runs/30468254213)) because those release notes happened to contain one semicolon. Any release body with a semicolon in it trips this. BentoBoxWorld/.github#13 fixed it on 2026-07-20 by writing the JSON to a file and using curl's `<file` form (`-F "metadata=<cf_meta.json;type=application/json"`). This repo was still pinned to the commit before that fix. Modrinth publishing is unaffected — it does not go through this workflow. No behaviour change beyond the fix; the pin is the only line touched. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

tastybento · 2026-07-20T01:22:05Z

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them — every HTML entity does — truncated the JSON part of the multipart upload, so CurseForge rejected metadata as invalid JSON (error 1002) and Hangar failed to read the request (HTTP 400). Seen on the AcidIsland 2.0.0 release: https://github.com/BentoBoxWorld/AcidIsland/actions/runs/29710523349

The <file form reads the part content out-of-band, so the payload can contain any characters. Validated by re-running the AcidIsland 2.0.0 publish pinned to this branch's SHA.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

curl's -F parses ; and , inside inline values as attribute separators. Any changelog containing them - every HTML entity does - truncated the JSON part, so CurseForge rejected metadata as invalid JSON and Hangar failed to read the request. The <file form reads content out-of-band and is immune to the payload's characters. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RJmrCPRxnwMnWQvGKpEpGY

The pinned SHA predates BentoBoxWorld/.github#13, which moved the CurseForge metadata and Hangar versionUpload JSON out of inline curl -F values and into files. curl treats a ';' in an inline -F value as the start of a type= attribute, so a release body containing a semicolon truncates the JSON and both platforms reject the upload. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

## What Bumps the pinned SHA of the shared `publish-platforms.yml` reusable workflow to `1f91a0e` (master HEAD of `BentoBoxWorld/.github`). ## Why The pinned version passes the CurseForge `metadata` and Hangar `versionUpload` multipart JSON as an inline curl value: ``` -F "metadata=${META};type=application/json" ``` curl reads a `;` inside an inline `-F` value as the start of a `type=`/`filename=` attribute, so the JSON is silently truncated at the first semicolon in the release body. Both platforms then reject the upload: - CurseForge — `{"errorCode":1002,"errorMessage":"Error in field \`metadata\`: Invalid JSON."}` - Hangar — `{"status":400,"detail":"Failed to read request"}` This is latent, not theoretical: it took down the AOneBlock 1.26.3 publish ([run](https://github.com/BentoBoxWorld/AOneBlock/actions/runs/30468254213)) because those release notes happened to contain one semicolon. Any release body with a semicolon in it trips this. BentoBoxWorld/.github#13 fixed it on 2026-07-20 by writing the JSON to a file and using curl's `<file` form (`-F "metadata=<cf_meta.json;type=application/json"`). This repo was still pinned to the commit before that fix. Modrinth publishing is unaffected — it does not go through this workflow. No behaviour change beyond the fix; the pin is the only line touched. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SAQ3YQkcfRoCZEwa6SPJcp

tastybento merged commit 1f91a0e into masterJul 20, 2026

tastybento deleted the fix/curl-form-inline-parsing branch July 20, 2026 01:30

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/AOneBlock#547
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/BentoBox#3047
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/Level#455
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/ChunkBlock#15
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/Border#181
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/InvSwitcher#62
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/AcidIsland#181
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/Challenges#426
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/Parkour#32
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/ControlPanel#42
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/MagicCobblestoneGenerator#171
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/GushBlock#1
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/Warps#164
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/Biomes#182
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/Boxed#132
Merged

tastybento mentioned this pull request Jul 29, 2026
ci: bump publish-platforms pin to the multipart-JSON fix BentoBoxWorld/BSkyBlock#556
Merged