A ChatGPT connector created against v1.0.8 can retain a workspaceId tool argument after the server upgrades to the canonical workspace_id schemas. I reproduced an authenticated read call using the previous field name against beta.4: it returned Input validation error: Invalid arguments for tool read: workspace_id: Invalid input: expected string, received undefined. The corresponding canonical call succeeded. The workspace was valid; neither the path nor authentication was the cause.
#339 already contains a report of this upgrade/schema mismatch, and #303 explicitly chose not to add compatibility aliases. This issue proposes a narrower migration boundary for that identified cached client: translate an old workspaceId argument for workspace-scoped tool calls immediately before normal validation. Keep advertised schemas canonical, reject conflicting old/new values, and preserve all tool authorization and path checks. It does not propose legacy aliases throughout the domain model or changing model/host behavior.
Refreshing tools or recreating a connector is the existing client-side workaround. A transition adapter would allow existing conversations to keep working while the host refreshes its descriptors. I have a local reproduction and will submit a small companion PR with the old call failing before the change and succeeding after it, plus conflicting/invalid-input coverage. This is a proposal for maintainer review; it is not a claim that the documented snake_case migration was accidental.
A ChatGPT connector created against v1.0.8 can retain a
workspaceIdtool argument after the server upgrades to the canonicalworkspace_idschemas. I reproduced an authenticatedreadcall using the previous field name against beta.4: it returnedInput validation error: Invalid arguments for tool read: workspace_id: Invalid input: expected string, received undefined. The corresponding canonical call succeeded. The workspace was valid; neither the path nor authentication was the cause.#339 already contains a report of this upgrade/schema mismatch, and #303 explicitly chose not to add compatibility aliases. This issue proposes a narrower migration boundary for that identified cached client: translate an old
workspaceIdargument for workspace-scoped tool calls immediately before normal validation. Keep advertised schemas canonical, reject conflicting old/new values, and preserve all tool authorization and path checks. It does not propose legacy aliases throughout the domain model or changing model/host behavior.Refreshing tools or recreating a connector is the existing client-side workaround. A transition adapter would allow existing conversations to keep working while the host refreshes its descriptors. I have a local reproduction and will submit a small companion PR with the old call failing before the change and succeeding after it, plus conflicting/invalid-input coverage. This is a proposal for maintainer review; it is not a claim that the documented snake_case migration was accidental.