Release/v1.0.6#5738
Conversation
Signed-off-by: prakhar-singh1928 <prakhar.singh1928@ibm.com>
Signed-off-by: cafalchio <mcafalchio@gmail.com>
Signed-off-by: cafalchio <mcafalchio@gmail.com>
Signed-off-by: cafalchio <mcafalchio@gmail.com>
Signed-off-by: cafalchio <mcafalchio@gmail.com>
brian-hussey
left a comment
brian-hussey
left a comment
There was a problem hiding this comment.
@cafalchio Will you capture the load test results as part of the release as well please?
I'm thinking docs/release/test-results/ with a particular md file with the summary.
@ja8zyjits This might not need to block release right now but I'd like an immediate update afterwards with this kind of detail for this point in time.
And we should update the release management steps to include this update as well.
Signed-off-by: cafalchio <mcafalchio@gmail.com>
|
@brian-hussey I have added the benchmark.md |
msureshkumar88
left a comment
msureshkumar88
left a comment
There was a problem hiding this comment.
Thanks for pulling this release together — consolidating 89 PRs into a coherent changelog is real work, and the mechanical bump is clean: .bumpversion.cfg, mcpgateway/__init__.py, Cargo.toml/Cargo.lock, pyproject.toml, uv.lock, and charts/mcp-stack/Chart.yaml are all consistent at 1.0.6.
A couple of things I checked and want to call out as good, since they're easy to get wrong:
- The cargo-vet pruning in
supply-chain/config.tomlis sound. The removed exemptions (aes-gcm,aead,ctr,ghash,dashmap,criterion,bstr) are all for crates no longer present inCargo.lock,hashbrownmoved 0.14.5 → 0.17.1 and is now publisher-covered, andnum-convis covered by the imported mozilla/zcash/ariel-os audits. TheSupply-chain vetjob is green, which matches. - The
check-manifestignore additions inpyproject.tomlline up with the new static bundle layout, and since it's check-manifest-only there's no wheel/packaging impact. .secrets.baselineis line-number shifts and a timestamp only — no new findings.
I compared the file set against the previous release PRs (#5509 for 1.0.5, #5311 for 1.0.4) and a few checklist steps from docs/docs/development/release-management.md look like they were missed. Grouping them below.
Blocking
1. SECURITY.md — a paragraph got dropped along with the version bump
**Current Version: 1.0.6**
-ContextForge is currently in beta and should be treated as such until the 1.0 release. While we implement comprehensive security measures and follow best practices, important limitations exist:This leaves ## ⚠️ Beta Software Notice as an orphan heading with nothing under it. #5509 touched only the version line here (+1/−1), so this looks unintentional — worth restoring.
2. CHANGELOG.md — the [Unreleased] entries were removed rather than migrated
Three entries were deleted from [Unreleased]. Only one made it into the 1.0.6 section, and as a bare PR title (fix: return 404 for missing server and gateway deletes #5672) with the behavior detail stripped. Two are gone entirely:
- Stricter
authheadersKey Validation (#5314) — this one is a documented breaking change with migration impact ("Gateway or A2A configs relying on the old behavior will need their header keys corrected on the next update"). - Custom Auth Headers on Tools (#5314 / #5201).
release-management.md §1.3 asks for a Breaking Changes section with migration tables, and 1.0.6 currently has none. Suggested addition under the 1.0.6 Overview:
### Breaking Changes
- **Stricter `authheaders` Key Validation (Gateways, Tools, A2A Agents)** ([#5314](https://github.com/IBM/mcp-context-forge/pull/5314)) - Header-key validation is now shared across all create/update schemas and the admin form. Keys with embedded whitespace (e.g. `X Api Key`) were previously accepted and stored as invalid HTTP header names that failed at invocation time; they are now rejected with a 422 at config time, and surrounding whitespace is trimmed before storage. Gateway or A2A configs relying on the old behavior will need their header keys corrected on the next update.3. Containerfile:375 — OCI version label still says 1.0.5
- org.opencontainers.image.version="1.0.5"
+ org.opencontainers.image.version="1.0.6"#5509 bumped Containerfile (+4/−4) for exactly this. As-is, the 1.0.6 images ship labeled 1.0.5, which shows up in registry metadata and the SBOM.
Side note: commit 2ffc39fa is titled "bump-version 1.0.5 -> 1.0.6 / update ubi packages" but there's no Containerfile change in the final diff — possible the base-image update (§1.6) got lost in a rebase?
4. Stale >=1.0.5 pins
git grep '1\.0\.5' turns up four that previous releases bumped:
pyproject.toml:330and:334— theall/dev-allmeta-extras (#5509 bumped these exact lines)plugins/external/opa/pyproject.toml:49plugins/external/cedar/pyproject.toml:49
Suggestions (non-blocking, but worth a look before tagging)
Dependency updates (§2 / §3) may be partial. uv.lock has no actual package upgrades — just the project version plus some resolver artifacts. For comparison, #5509 moved real pins (e.g. pydantic-settings>=2.14.1 → 2.14.2), and the npm lock here only picked up dev deps (biome 2.5.2 → 2.5.4, lru-cache). The release notes mention dependency updates under Infrastructure, so these may just be out of sync — or the uv lock --upgrade sweep hasn't run yet.
uv.lock reproducibility cutoff. The absolute exclude-newer was replaced with a sentinel:
-exclude-newer = "2026-07-06T09:32:49.364341Z"
+exclude-newer = "0001-01-01T00:00:00Z" # This has no effect...Resolution is now governed only by the relative exclude-newer-span = "P10D", which means each re-lock drifts rather than pinning to a fixed date. This looks like an artifact of a newer uv writing the file. Is that the intended behavior going forward?
uv.lock marker relaxation. aiologic and culsans lost their python_full_version < '3.13' markers on sniffio / wrapt / typing-extensions, so those now install on 3.13+ as well. Almost certainly benign, but it is an unremarked change to the installed dependency set in a release lock.
tests/performance/benchmark.md. The table reports 7.83% and 31.56% failure rates, a max response of 85.5s, and p99 sitting right at the 30s timeout. Useful data to track, but published as-is it reads like a known-bad release. A sentence on whether those failures are load-generator saturation vs. real gateway errors would go a long way — or the numbers could live outside the release PR.
Minor: scripts/release-automation/release-checks.json (844 lines) is added in 2ffc39fa and gone by the head commit. Net-zero, so no impact — just checking the removal was deliberate and not a rebase casualty.
Happy to re-review once the four blocking items are in. CI is otherwise green apart from pytest (py3.12) and pytest-rust, which were still pending when I looked.
|
Some of the ui-rewrite stuff is merged to a feature branch, e.g. #5564. Do we have to mention that into the changelog as changelog is about what got merged to the context-forge main branch? |
Nice catch, @gandhipratik203, changes on the UI rewrite branch should not be on the changelog, for now. |
msureshkumar88
left a comment
msureshkumar88
left a comment
There was a problem hiding this comment.
Follow-up to my earlier review — two more CHANGELOG.md items surfaced while cross-checking the 1.0.6 section against the previous release sections and the open issue tracker. Both are changelog-only, no code involved.
1. Known Issues section is missing, and four open release-time-findings issues aren't documented
All four issues currently carrying the release-time-findings label are open and unmentioned in the 1.0.6 section:
| Issue | Opened | Summary |
|---|---|---|
| #5739 | 2026-07-21 | Saving LLM Provider/Model in Admin UI fails with 403 CSRF validation failed |
| #5740 | 2026-07-21 | LLM Chat sessions are in-memory only (redis_client hardcoded None) — breaks under multi-worker gunicorn |
| #5215 | 2026-06-12 | LLM Chat cannot connect to a Virtual Server on the same gateway — forwarded session token rejected (401) |
| #5526 | 2026-07-06 | Tools table row action button not found for JSON-schema test tool |
There's good precedent for documenting these — the 1.0.3 section (CHANGELOG.md:527) carries a ### Known Issues block with an issue link and a concrete workaround, which is exactly the shape that helps here.
Two of these feel worth prioritising:
- #5739 looks like a recurrence of #5151 — the same
CSRF validation failedclass of failure that 1.0.3 explicitly documented, workaround and all. Regressing on a previously-documented known issue without re-documenting it is probably the most confusing outcome for anyone upgrading. - #5740 is a deployment-topology hazard. With
redis_clienthardcoded toNone, LLM Chat sessions aren't shared across workers — and multi-worker gunicorn is the defaultmake servepath. Undocumented, that surfaces to users as intermittent, non-deterministic session loss with nothing to search for.
Suggested block for the 1.0.6 section, following the 1.0.3 format:
### Known Issues
- **🔒 CSRF Validation Failure Saving LLM Provider/Model** ([#5739](https://github.com/IBM/mcp-context-forge/issues/5739)) – Saving an LLM Provider or Model in the Admin UI fails with `403 CSRF validation failed`. Related to the previously reported [#5151](https://github.com/IBM/mcp-context-forge/issues/5151).
- **Workaround:** Copy the `CSRF_EXEMPT_PATHS` value from `.env.example` into your `.env` and restart the application.
- **💬 LLM Chat Sessions Are In-Memory Only** ([#5740](https://github.com/IBM/mcp-context-forge/issues/5740)) – `redis_client` is hardcoded to `None`, so chat sessions are not shared across workers and are lost on restart. Under multi-worker gunicorn (the default for `make serve`), sessions will appear to drop intermittently.
- **Workaround:** Run a single worker if session continuity is required.
- **🔗 LLM Chat Cannot Connect to a Same-Gateway Virtual Server** ([#5215](https://github.com/IBM/mcp-context-forge/issues/5215)) – The forwarded session token is rejected with a 401 by `/servers/{id}/mcp`.
- **🧪 Tools Table Row Action Button Not Found** ([#5526](https://github.com/IBM/mcp-context-forge/issues/5526)) – Affects the JSON-schema test tool.Happy to trim the list if some of these are considered already-fixed or out of scope for 1.0.6 — the main ask is that #5739 and #5740 get a mention with a workaround.
2. CHANGELOG.md:132 — the previous release PR is listed as a 1.0.6 change
- **Release/v1.0.5** ([#5509](https://github.com/IBM/mcp-context-forge/pull/5509))#5509 is the 1.0.5 release PR itself. It merged into main during the 1.0.6 window, so an auto-generated merged-PR list would pick it up — but it carries no user-facing change, and its actual content is the ## [1.0.5] section six lines further down.
Worth noting the earlier sections don't do this: neither 1.0.5 (no reference to #5311 / Release/v1.0.4) nor 1.0.4 self-reference the prior release PR, so this looks like a filtering difference in how the 1.0.6 list was produced rather than an intentional change.
Suggested fix: drop line 132. #5710 ("Update roadmap for 1.0.6") is arguably in the same category, though it's more defensible as release-process history — your call on that one.
Both are small edits and can ride along with the other CHANGELOG.md changes from my first review (restoring the dropped [Unreleased] entries and adding the Breaking Changes section).
msureshkumar88
left a comment
msureshkumar88
left a comment
There was a problem hiding this comment.
Third and last pass from me. I reconciled the 1.0.6 CHANGELOG section against what actually landed on main since the 1.0.5 release PR (#5509, merged 2026-07-07T11:01:04Z), and the two lists diverge in both directions. Flagging it before the tag goes out because one half affects what users are told they're getting.
First, the good news: the branch itself is in good shape. origin/main is 0 commits ahead of the branch head, so nothing that landed on main is missing from the release artifact. The gap is entirely in the changelog.
1. Twenty-six changelog entries describe code that isn't in the release
The UI Modernization block is the largest section in the 1.0.6 notes, and the release title leads with "UI Rewrite". Those PRs merged into epic/ui-rewrite, not into main:
$ git merge-base --is-ancestor origin/epic/ui-rewrite origin/main
# non-zero — not contained
$ git rev-list --count origin/main..origin/epic/ui-rewrite
302
There's no PR open or merged from epic/ui-rewrite into main, and the client/ tree doesn't exist on the release branch at all:
$ git ls-tree 0a2db45ad --name-only | grep -c '^client$'
0
Spot-checking #5707's files against the branch, they're all absent (client/src/components/gateways/CreateServerForm.tsx, client/src/components/layout/HeaderQuickNav.tsx, and the rest).
Affected entries: #5375, #5398, #5512, #5518, #5540, #5541, #5546, #5548, #5550, #5561, #5564, #5575, #5604, #5606, #5609, #5612, #5632, #5636, #5638, #5662, #5666, #5670, #5675, #5695, #5707.
Also in this bucket, for a different reason: #5678 ("OCP SCC UID compatibility and Helm volumeMounts indentation") merged into fix/ensure_helm_chart_in_ci, whose PR to main (#5269) is still open — so that fix isn't shipping either.
I suspect the list was generated from merged PRs across all base branches rather than filtered to main, which would explain it cleanly. Two ways forward depending on the release plan:
- If
epic/ui-rewriteis meant to ship in 1.0.6, it needs to land onmainbefore tagging. - If it isn't, these entries should move to
[Unreleased]and the release title probably shouldn't lead with "UI Rewrite".
Either is fine — the thing to avoid is tagging with the notes advertising a React UI that isn't in the artifact.
2. Nine PRs that did land on main have no changelog entry
All nine merged with base=main inside the release window, and git merge-base --is-ancestor <merge_sha> 0a2db45ad confirms each is in the branch:
| PR | Merged | Size | Title |
|---|---|---|---|
| #5224 | 07-13 | +3679/−69, 27 files | feat(oauth): RFC 8693 token exchange (On-Behalf-Of) for OAuth gateways — security, MUST |
| #4821 | 07-20 | +468/−109, 12 files | fix(auth): unify email extraction across all resource operations — bug, MUST, regression |
| #5314 | 07-15 | +838/−203, 10 files | fix(schemas): persist auth_headers array in POST/PUT /tools |
| #5470 | 07-13 | +2967/−154, 29 files | feat(plugins): build + consume CPEX plugin trace context and metrics (G0+G1) |
| #5430 | 07-15 | +1231/−54, 22 files | feat(plugins): restrict non-hook plugin init to a single worker across instances |
| #5611 | 07-15 | +1489/−100, 10 files | feat(plugins): consume metrics from 5 remaining bundled cpex-* plugins |
| #5406 | 07-13 | +488/−31, 14 files | fix(plugins): restrict non-hook plugin initialization to a single worker |
| #5637 | 07-16 | +1515/−2674, 1280 files | Update fix_file_headers generic default AUTHOR/COPYRIGHT |
| #5513 | 07-08 | +53/−73, 3 files | ci(plugins): replace fast-time-server source build with pre-built image |
Three of these fall into categories release-management.md §1.3 asks for by name, and I'd treat them as the ones that really need entries:
- #5224 adds a new OAuth grant with a new trust boundary —
AGENTS.mddescribestoken_urlon a token-exchange gateway as an SSRF/egress boundary that receives the user's ContextForge JWT assubject_token, and notes that creating such gateways is a privileged action. It also ships an ADR (adr/041-identity-propagation.md) and two docs pages. Worth aSecurityentry. - #4821 changes which principal RBAC evaluates and which identity appears in audit logs (the email-over-sub precedence work). It's labelled
regression, so it's fixing something users hit. Worth aFixedentry. - #5314 is the breaking change whose
[Unreleased]text was removed in this PR — covered in my first review, but it shows up here independently, which is a useful cross-check.
The plugin worker-initialization pair (#5406, #5430) and the CPEX metrics pair (#5470, #5611) change behaviour operators will notice under multi-worker gunicorn, so a Changed line each would help. #5513 is CI-only and #5637 is a mechanical header rewrite — both fine to omit, though #5637 touching 1280 files might be worth one line so nobody is startled by the diff.
Reconciliation
| Count | |
|---|---|
| PR description claims | 89 |
| CHANGELOG cites | 79 |
Actually landed on main since 1.0.5 |
61 |
| Cited but not shipping | 26 |
| Shipping but not cited | 9 |
If it's useful, filtering the generated list on base=main and cross-checking against git log <last-release-sha>..HEAD --pretty=%s should close both gaps in one pass — the repo squash-merges, so PR numbers come out of the commit subjects reliably.
Happy to re-review once this and the earlier items are sorted. Thanks for bearing with three rounds on this one — the release-notes accuracy felt worth getting right before the tag is cut.
Signed-off-by: prakhar-singh1928 <prakhar.singh1928@ibm.com>
|
For @msureshkumar88's (#5738 (review)) above: Should be removed,if there is a trailing Beta Software notice that should be removed too.
|
Signed-off-by: cafalchio <mcafalchio@gmail.com>
brian-hussey
left a comment
brian-hussey
left a comment
There was a problem hiding this comment.
One small change, linked to what @msureshkumar88 had identified before.
msureshkumar88
left a comment
msureshkumar88
left a comment
There was a problem hiding this comment.
Re-reviewed at 07ded2c6a. Almost everything from the previous three rounds is in — thanks for working through all of it, that was a lot of changelog reconciliation.
Confirmed fixed:
Containerfile:375now labels1.0.6.- All four stale
>=1.0.5pins are gone (pyproject.tomlall/dev-all,plugins/external/opa,plugins/external/cedar). ### Breaking Changesis in the 1.0.6 section with theauth_headersentry and a before/after migration table.### Known Issuescovers all fourrelease-time-findingsissues (#5739, #5740, #5215, #5526) with workarounds on the two that needed them.- The #5509 self-reference is dropped.
- All 25
epic/ui-rewriteentries are removed, and the nine PRs that did land onmain(#5224, #4821, #5314, #5470, #5430, #5611, #5406, #5637, #5513) now have entries.
Two things are left, both one-liners.
Blocking
1. SECURITY.md — heading is now orphaned
The paragraph came out, but the heading it belonged to is still there with nothing under it:
# 🔐 Security Policy
## ⚠️ Beta Software Notice
**Current Version: 1.0.6**
### Admin UI is Development-OnlyPer @brian-hussey's note ("if there is a trailing Beta Software notice that should be removed too"), the ## ⚠️ Beta Software Notice heading should go as well. **Current Version: 1.0.6** can either move up under the top-level heading or get its own line — either reads fine, it just shouldn't sit under an empty section header.
2. CHANGELOG.md:118 — #5678 isn't shipping in this artifact
- **OCP SCC UID Compatibility** ([#5678](https://github.com/IBM/mcp-context-forge/pull/5678)) - Fixed OCP SCC UID compatibility and Helm volumeMounts indentation.#5678 merged with base=fix/ensure_helm_chart_in_ci, and that branch's PR to main (#5269, "fix(helm): resolve Helm chart linting issues") is still open — so the fix isn't in the release branch. Same category as the epic/ui-rewrite entries; it just survived the cleanup pass. Either move it to [Unreleased], or land #5269 before tagging if the Helm fix is meant to be in 1.0.6.
Non-blocking
[Unreleased]is now empty. The entries were correctly migrated, but @brian-hussey's point was that the section itself is how we track items still needing docs during the iteration. Worth keeping a placeholder there rather than leaving it bare — your call whether that matters before the tag.- Benchmark placement. @brian-hussey asked for
docs/release/test-results/with a summary md; the results currently live attests/performance/benchmark.md. Also still no note on whether the 7.83% / 31.56% failure rates are load-generator saturation or real gateway errors — one sentence there would stop the numbers reading as a known-bad release. uv.lockexclude-newer. Still"0001-01-01T00:00:00Z"withexclude-newer-span = "P10D", so resolution drifts on each re-lock rather than pinning to a fixed date. Fine if that's the intended direction now that uv writes it this way — just want to confirm it's deliberate rather than an artifact.
Happy to approve once the two blocking items are in.
Signed-off-by: cafalchio <mcafalchio@gmail.com>
msureshkumar88
left a comment
msureshkumar88
left a comment
There was a problem hiding this comment.
Re-reviewed at 29ca93c7e. Thanks for the quick turnaround on the SECURITY.md item.
Confirmed fixed:
SECURITY.md— the orphaned## ⚠️ Beta Software Noticeheading is gone, and**Current Version: 1.0.6**now sits directly under the top-level heading. That resolves @brian-hussey's note.
Everything else confirmed in the previous round is untouched — the only commit since 07ded2c6a is the two-line SECURITY.md deletion.
That leaves one blocking item from the last review, which I don't think was picked up.
Blocking
CHANGELOG.md:118 — #5678 still listed under 1.0.6, but isn't in the artifact
#### **Build & Infrastructure**
- **OCP SCC UID Compatibility** ([#5678](https://github.com/IBM/mcp-context-forge/pull/5678)) - Fixed OCP SCC UID compatibility and Helm volumeMounts indentation.Re-verified against the current head:
$ gh pr view 5269 --json state,mergedAt,baseRefName
{"baseRefName":"main","mergedAt":null,"state":"OPEN"}
$ git log --oneline origin/Release/v1.0.6 | grep '#5678'
# no match
#5678 merged with base=fix/ensure_helm_chart_in_ci, and that branch's PR to main (#5269, "fix(helm): resolve Helm chart linting issues") is still open — so the Helm/SCC fix isn't on the release branch. Same category as the epic/ui-rewrite entries that were cleaned up; this one just survived the pass.
Two ways to close it, whichever fits the release plan:
- Move the line to
[Unreleased]— this also gives that section the placeholder @brian-hussey wanted, so it'd close both items at once. - Or land #5269 before tagging, if the Helm fix is meant to be in 1.0.6.
The concern is only that a user reading the 1.0.6 notes would expect the OCP SCC UID fix to be in the image, and it isn't.
Non-blocking (carried over, no change needed to approve)
- Benchmark results are still at
tests/performance/benchmark.mdrather thandocs/release/test-results/with a summary, and there's still no note on whether the 7.83% / 31.56% figures are load-generator saturation or real gateway errors. One sentence would stop those numbers reading as a known-bad release. uv.lockstill hasexclude-newer = "0001-01-01T00:00:00Z"withexclude-newer-span = "P10D". Fine if that's deliberate now that uv writes it this way — just flagging so it's a choice rather than an artifact.
Happy to approve as soon as the changelog line is moved (or #5269 lands). Sorry to hold on a one-liner after everything else you've reconciled — it's the last one from my side.
Signed-off-by: cafalchio <mcafalchio@gmail.com>
76890d8
msureshkumar88
left a comment
msureshkumar88
left a comment
There was a problem hiding this comment.
Re-reviewed at 76890d861. The #5678 entry is out of the Build & Infrastructure list and the PR count is correctly adjusted 89 → 88 — thanks for that, and for moving the benchmark to docs/release/.
One residual of the same item, in the Overview bullet rather than the entry list.
Blocking
CHANGELOG.md:25 — Overview still advertises the OCP SCC UID fix
07ded2c6a..76890d861 removed "Helm volumeMounts indentation fix" from this line but left the other half:
- **CI / DevOps** - PR-scoped pyright workflow, s390x build flag, remove Slack direct-merge notification, remove Renovate in favour of Dependabot, Redis maxclients increase, OCP SCC UID compatibility.Both halves came from #5678, which still isn't in the artifact:
$ gh pr view 5269 --json state,mergedAt
{"mergedAt":null,"state":"OPEN"}
$ git grep -n 'runAsUser' origin/Release/v1.0.6 -- charts/
charts/mcp-stack/values.yaml:157: runAsUser: 10001
charts/mcp-stack/templates/job-migration.yaml:31: runAsUser: 10001
The hardcoded UID that #5678 removes is still there, so a user reading the 1.0.6 Overview would expect SCC compatibility in the image and not get it — same concern as the entry that was just removed.
Exact fix:
-- **CI / DevOps** - PR-scoped pyright workflow, s390x build flag, remove Slack direct-merge notification, remove Renovate in favour of Dependabot, Redis maxclients increase, OCP SCC UID compatibility.
+- **CI / DevOps** - PR-scoped pyright workflow, s390x build flag, remove Slack direct-merge notification, remove Renovate in favour of Dependabot, Redis maxclients increase.Or land #5269 before tagging, if the Helm/SCC fix is meant to be in 1.0.6.
Happy to approve as soon as this line is in — it's the last blocking one from my side.
Signed-off-by: prakhar-singh1928 <prakhar.singh1928@ibm.com>
msureshkumar88
left a comment
msureshkumar88
left a comment
There was a problem hiding this comment.
Re-reviewed at f3f0950cd. The last blocking item is closed — thanks for staying with this through five rounds of changelog reconciliation, that was a lot of cross-checking.
Confirmed fixed:
CHANGELOG.md:25— "OCP SCC UID compatibility" is out of the CI / DevOps Overview bullet. The line now reads through "Redis maxclients increase", with no reference to #5678 anywhere in the 1.0.6 section:
$ git grep -n -iE 'OCP|SCC|5678' origin/Release/v1.0.6 -- CHANGELOG.md
CHANGELOG.md:893: ... (1.0.3 section)
CHANGELOG.md:951: ... (1.0.3 section)
Both remaining hits are in the historical 1.0.3 block, which is correct.
Full recap of what's now resolved across the earlier rounds:
SECURITY.md— beta paragraph and its orphaned## ⚠️ Beta Software Noticeheading removed;**Current Version: 1.0.6**sits under the top-level heading.Containerfile:375labels 1.0.6, and all four stale>=1.0.5pins are gone (pyproject.tomlall/dev-all,plugins/external/opa,plugins/external/cedar).### Breaking Changescoversauth_headerswith a before/after migration table.### Known Issuescovers all fourrelease-time-findingsissues (#5739, #5740, #5215, #5526), with workarounds on the two that needed them.- All 25
epic/ui-rewriteentries removed, the nine PRs that did land onmainadded, and the #5678 entry dropped with the PR count adjusted 89 → 88. - Load-test summary captured at
docs/release/benchmark.md, per @brian-hussey's request.
The version bump itself remains consistent across .bumpversion.cfg, mcpgateway/__init__.py, Cargo.toml/Cargo.lock, pyproject.toml, uv.lock, and charts/mcp-stack/Chart.yaml, and origin/main is still 0 commits ahead of the branch head, so the artifact matches what's documented.
LGTM — good to tag.
Signed-off-by: cafalchio <mcafalchio@gmail.com>
9661c09
brian-hussey
left a comment
brian-hussey
left a comment
There was a problem hiding this comment.
LGTM. Thanks @cafalchio and @prakhar-singh1928 and team!
8 participants
[1.0.6] - 2026-07-22 - OAuth Token Exchange, Vault Credentials, MCP Apps, Dataplane Publishing, and Security Hardening
Overview
Release 1.0.6 consolidates 61 PRs focused on OAuth RFC 8693 token exchange, HashiCorp Vault per-user credential resolution, MCP Apps support, dataplane resource and tool publishing, SSRF/TLS security hardening, plugin observability, and CI/DevOps improvements:
Breaking Changes
Stricter
auth_headersKey Validation (Gateways, Tools, A2A Agents) (#5314) - Header-key validation is now shared across all create/update schemas and the admin form. Keys with embedded whitespace (e.g.X Api Key) were previously accepted and stored as invalid HTTP header names that failed at invocation time; they are now rejected with a 422 at config time, and surrounding whitespace is trimmed before storage. Gateway or A2A configs relying on the old behaviour will need their header keys corrected on the next update.X Api KeyAuthorizationAuthorization(trimmed)Added
API & Platform
OAuth & Auth
Vault
Plugins & Observability
Dataplane
Changed
API
POST /toolsandPUT /tools/{tool_id}now correctly persist theauth_headersarray instead of silently storingauth_value: null. Invalid header keys/values are rejected with a 422 rather than an unhandled 500.Build & Packaging
contextforge-examplesrepository.Fixed
Security
GrpcEndpoint.start().oauth_configURLs to prevent SSRF during gateway registration.ssrf_protection_enabledglobal flag in the gateway test endpoint.Auth
API & Database
DELETE /servers/{id}andDELETE /gateways/{id}now return404 Not Foundinstead of403 Forbiddenwhen the target does not exist.bootstrap_resource_assignmentson concurrent pod restart.Dataplane & Transport
original_nameinallowed_tool_namesfrom the dataplane publisher.A2A
Plugins
Build & Infrastructure
maxclientsfrom 10000 to 15000 and reduced max connections.Documentation
Known Issues
403 CSRF validation failed. Recurrence of the class of failure documented in #5151.CSRF_EXEMPT_PATHSvalue from.env.exampleinto your.envand restart the application.redis_clientis hardcoded toNone, so chat sessions are not shared across workers and are lost on process restart. Under multi-worker gunicorn (the default formake serve), sessions will drop intermittently with no diagnostic message.--workers 1) if session continuity is required./servers/{id}/mcpwhen LLM Chat targets a Virtual Server on the same gateway instance.Chores