[Windows][Desktop][Plugins] Neon Postgres wrappers use stale camelCase schemas and fail strict validation

What version of Codex are you using?

• Codex Desktop on Windows
• Bundled CLI: codex-cli 0.150.0-alpha.12.2
• Windows build: 26200.9168, x64
• Observed: 2026-08-30

What issue are you seeing?

The installed curated Neon Postgres plugin exposes stale camelCase tool schemas even though the live Neon MCP server now requires strict snake_case arguments.

Affected remote app:

asdk_app_69e0086d87088191a3edc052fa50c29f

For example, Codex currently exposes this wrapper:

run_sql({
  projectId: string,
  branchId?: string,
  databaseName?: string,
  sql: string
})

The live Neon server expects:

run_sql({
  project_id: string,
  branch_id?: string,
  database_name?: string,
  sql: string
})

Calling the Codex wrapper fails before any SQL executes:

MCP error -32602: Input validation error
expected string at path project_id
unrecognized keys projectId, branchId, databaseName

Neon deliberately moved every tool argument to strict snake_case in:

• https://github.com/neondatabase/mcp-server-neon/pull/324
• https://mcp.neon.tech/api/list-tools

The live tool catalogue returns strict schemas with additionalProperties: false, so camelCase aliases cannot be accepted.

A local audit of the currently exposed Codex tools found 29 Neon wrappers. At least 20 still declare one or more stale camelCase fields, including projectId, branchId, databaseName, branchName, and sqlStatements.

The affected surface includes project description, branch creation, SQL execution, transactions, connection details, schema inspection, migrations and tuning. Simple list/search/fetch/documentation tools remain usable, which can make the plugin appear partially healthy.

Steps to reproduce

1. Install or enable the curated Neon Postgres plugin in Codex Desktop.
2. Inspect the exposed schema for neon_postgres_run_sql or neon_postgres_describe_project.
3. Observe that the wrapper requires projectId rather than project_id.
4. Invoke the wrapper with a valid, redacted Neon project ID.
5. Observe the upstream strict-schema validation error before the operation executes.

No database mutation is required to reproduce this. A read-only describe_project call is sufficient.

Expected behaviour

The hosted connector runtime snapshot for app asdk_app_69e0086d87088191a3edc052fa50c29f should be republished from the current live Neon MCP schemas so Codex exposes strict snake_case arguments.

After repair, these read-only canaries should succeed:

{"project_id":"<redacted-project-id>"}

for describe_project, followed by:

{"project_id":"<redacted-project-id>","branch_id":"<redacted-non-default-branch-id>","sql":"SELECT 1"}

for run_sql.

Additional diagnostic information

The current app-server protocol exposes app/installed with forceRefresh, but it republishes the whole installed connector runtime snapshot and accepts no app ID selector. app/read accepts appIds, but is metadata-only and cannot refresh runtime schemas. There is no supported app-ID-scoped refresh command in the current app-server or CLI.

I did not invoke the snapshot-wide refresh because it could affect unrelated installed connectors. I also did not patch local caches, change global MCP configuration, or execute SQL.

Please republish the remote app schema for the exact app ID above, or add an app-ID-scoped refresh operation so stale connector schemas can be repaired without refreshing every installed app.

Start with the app/installed forceRefresh and app/read appIds behavior described in the issue, then trace how the hosted connector runtime snapshot is published for the specified app ID. Done means the Neon schemas expose strict snake_case arguments and the read-only describe_project and run_sql canaries succeed without validation errors.