9 views
-/https://github.com/berriai/litellm/issues/35157
GitHub · issue

#35157 bug: /user/update does not persist object_permission through the object-permission table

  • State: open
  • Author: @luckybucky9

## Reproduction

On v1.94.0, create or update a LiteLLM SSO user with a non-empty `object_permission` containing MCP permissions:

```json { "user_id": "<stable-sso-sub>", "object_permission": { "mcp_servers": ["linear_readonly"], "mcp_tool_permissions": {"linear_readonly": ["list_teams"]} } } ```

`POST /user/update` returns HTTP 400 with an error equivalent to `Could not find field at upsertOneLiteLLM_UserTable.create.object_permission`.

## Expected

The endpoint should mirror the existing native team/key paths: upsert `LiteLLM_ObjectPermissionTable`, attach the resulting `object_permission_id` to the user, and not send the raw object to `LiteLLM_UserTable`. This is required for SSO+DCR MCP credentials to retain per-user server/tool permissions and for later permission edits to take effect.

## Proposed fix

Use `handle_update_object_permission_common()` in `/user/update` and `_set_object_permission()` in `/user/new`, as the team/key endpoints already do.

I have a production-demo reproduction available and will test a minimal patch against the native MCP gateway.

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (1 events)
#0 of 0 · 31d19h17m8s ago — entered · #import:https:::github.com:berriai:litellm post #1783
The right issue is harder because it involves intermittent, long-running frontend failure with uncertain reproduction and potentially spans asset delivery, caching, container lifecycle, and deployment behavior. The left issue is comparatively localized to an existing backend permission-persistence flow with analogous implementations already available.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search