feat: rebuild shared projects with locks and git activity history

[johannhartmann]

Summary

• Rebuild shared projects screen with project locking, member management, and git activity history
• Add lock/unlock flow so only one user edits a project at a time, with modal prompts for session claiming
• Surface GitLab commit history in the project UI via new git sync service endpoints

Test plan

• Verify project locking prevents concurrent edits
• Verify session claimed modal appears when another user takes over
• Verify git activity history renders commit log correctly
• Verify member management (add/remove) works end-to-end
• Run uv run pytest — all new and existing tests pass
• Run npm run build — no TypeScript errors

In general, to fix this kind of issue, avoid returning exception messages or stack traces directly in HTTP responses. Instead, log the detailed error server-side (if needed) and return a generic or controlled error code/message to the client.

For this specific case, we should stop sending str(e) back to the user and instead send a fixed error identifier derived from the same information currently used to compute the status code. The rest of the behavior (which status code is returned) can stay unchanged, preserving functionality from the client’s perspective while removing the information exposure.

Concretely, in src/runtimes/ws_server.py:

• In api_project_members_add, replace {"error": str(e)} with a small set of fixed tokens based on the same string that is currently used ("not_authenticated", "not_found", or "forbidden").
• In api_project_members_remove_by_sub, apply the same pattern to the except PermissionError as e: block.
• Optionally, we can log the original exception message with the logging module (already imported as logging) for debugging, but avoid including it in the HTTP response.

No new imports or helper methods are strictly necessary; we can implement the mapping inline where the JSONResponse is constructed.

In general, to fix this problem you should avoid returning raw exception messages or stack traces directly to users. Instead, map exceptions to controlled, stable error codes or messages, and log the detailed exception (including stack trace) on the server side for diagnostics. This ensures that clients receive only intended information, while developers retain full context via logs.

For this specific endpoint in src/runtimes/ws_server.py, we already derive an HTTP status code from the PermissionError’s string value, and we appear to be using constrained values like "not_authenticated" and "not_found". The safest way to preserve existing behavior while eliminating the information-exposure pattern is:

• Replace {"error": str(e)} with a sanitized, controlled error code that does not rely on arbitrary exception messages.
• Since the code already derives code from str(e), we can preserve the same categorization, but we should no longer echo str(e) itself back to the client. Instead, we can:
  • Map "not_authenticated" → "not_authenticated",
  • "not_found" → "not_found",
  • any other case → "forbidden".
• Optionally, to aid debugging without changing imports, we can log the exception using the existing logging module already imported at the top of the file, but only on the server side and not in the response body.

Concretely, in api_project_members_remove_by_email around lines 1221–1231:

• Keep the try/except PermissionError as e structure.
• Inside the except, keep the code computation, but add a small mapping to a safe error_code string that does not depend directly on str(e) for the client response.
• Optionally log the exception via logging.exception("...") or logging.warning(...).

This requires no new imports or external dependencies, as logging is already imported.

In general, the fix is to avoid returning raw exception messages to the client and instead return a generic, non-sensitive error code or message. Optionally, we can log the original exception on the server for debugging purposes, but the client should only see controlled values.

For this specific code at lines 1321–1323 in src/runtimes/ws_server.py, the best fix without changing behavior is to keep using the existing distinction between "not_authenticated" and other PermissionError conditions but avoid exposing the full exception string. A safe pattern is:

• Map "not_authenticated" to a stable, non-sensitive error identifier like "not_authenticated".
• Map all other PermissionError cases to another stable identifier like "forbidden" or "not_found" (since the current code uses 404).
• Optionally log the exception via the existing logging module for diagnostics, but do not send its message back to the client.

Concretely:

• At the except PermissionError as e: block, introduce a small mapping from str(e) to a controlled error code. For instance, if str(e) == "not_authenticated", return {"error": "not_authenticated"} with status 401, otherwise return {"error": "not_found"} with status 404.
• Do not change any imports; logging is already imported at line 7. We can log the exception using logging.warning or logging.error if desired, but this is optional security-wise.
• The changes are confined to the except PermissionError handler within api_git_sync_project in src/runtimes/ws_server.py.

In general, to fix this kind of issue you should avoid returning raw exception messages or stack traces in API responses. Instead, log the detailed error on the server (including the stack trace and repr(e)), and return a generic, user-safe error message or a stable error code. This preserves debuggability for developers while preventing attackers from learning about internal implementation details.

For this specific case, we should change the except Exception as e: block around the GitLab commit listing call (lines 1601–1614). Instead of including str(e) in the "detail" field of the JSON response, we should log the exception server-side using the existing logging module (already imported at the top of the file) and return a generic error object without any sensitive details. The surrounding code already distinguishes certain GitLab error states above (e.g., "gitlab_error" cases) and uses "gitlab_error" without details in one branch, so returning a simple "git_history_failed" without "detail" is consistent with existing patterns and does not alter control flow.

Concretely:

• In src/runtimes/ws_server.py, locate the try/except that calls GitLabClient.from_env().list_project_commits.
• Inside the except Exception as e::
  • Add a log statement such as logging.exception("Failed to list GitLab project commits") to capture the full stack trace on the server.
  • Change the JSONResponse payload so it no longer includes str(e), returning only {"error": "git_history_failed"}.
• No new imports are needed (the logging module is already imported on line 7).

In general, to fix this category of issue you should avoid returning raw exception messages (or stack traces) directly to the client. Instead, log the detailed error server-side (if needed) and send a generic, controlled error code or message in the HTTP response. This ensures developers can still debug, but untrusted clients do not see internals.

For this specific endpoint in src/runtimes/ws_server.py, the problematic code is:

1651:     except PermissionError as e:
1652:         code = 401 if str(e) == "not_authenticated" else 404
1653:         return JSONResponse({"error": str(e)}, status_code=code)

The best minimal fix without changing behavior from the client’s perspective is:

• Replace returning str(e) with a controlled, non-sensitive error identifier.
• Since the code already uses the string value of the exception to choose between 401 and 404, we can continue to use that internally but normalize what we send back.
• A simple approach is to:
  • Map "not_authenticated" to a fixed "not_authenticated" error code.
  • Map all other cases to a generic "not_found" (or similar) error code.
• Optionally, log the full exception message at server-side using the existing logging facilities (logging.getLogger(__name__) is already likely used earlier in the file). However, since we don’t see the logger here and we must minimize changes, we can just stop exposing str(e) externally.

Concretely, edit the except PermissionError block in api_git_pull_project so it becomes:

    except PermissionError as e:
        msg = str(e)
        code = 401 if msg == "not_authenticated" else 404
        error_code = "not_authenticated" if msg == "not_authenticated" else "not_found"
        return JSONResponse({"error": error_code}, status_code=code)

This keeps the existing semantics (401 for unauthenticated, 404 otherwise) but no longer leaks arbitrary exception text to clients.

In general, the fix is to avoid sending raw exception messages back to clients. Instead, send a generic or controlled error code/message, and if needed, log the detailed exception server-side for debugging. This prevents accidental leakage of stack traces or sensitive internal details through error responses.

For this specific handler in src/runtimes/ws_server.py, we should:

• Keep the logic that chooses 401 vs 404 based on the exception message ("not_authenticated" vs other).
• Stop returning str(e) to the client.
• Replace it with a controlled error code string that does not depend on the full exception text, while preserving the 401/404 behavior.
• Optionally, log the original exception using the existing logging infrastructure (there is already an imported logging module at the top of the file).

The minimal, behavior-preserving change is:

• In the except PermissionError as e: block, derive an error code like "not_authenticated" or "not_found" from the same condition used to set the status code and return that instead of str(e). That way, clients still get a useful, stable string, but we no longer expose arbitrary exception text.

Concretely:

• In src/runtimes/ws_server.py, around lines 2542–2544, change:
  • code = 401 if str(e) == "not_authenticated" else 404
  • return JSONResponse({"error": str(e)}, status_code=code)
• To:
  • Determine error_code based on the same comparison.
  • Optionally log the error.
  • return JSONResponse({"error": error_code}, status_code=code)

No new imports are strictly necessary; logging is already imported if we want to log the error.