[AGE-3374] [Bug] Invited users receive 401 Unauthorized after successful signup - cannot join workspace

[Rohitkhapre]

Labels: bug, authentication, self-hosted, invitation

---

Bug Summary

Invited users can successfully create accounts but receive 401 Unauthorized errors when attempting to access workspace resources, preventing them from joining the organization in Agenta OSS self-hosted deployments.

---

Steps to Reproduce

1. Organization owner sends invitation via Agenta UI.
2. User receives invitation email and clicks the invitation link.
3. User successfully creates account (signup endpoint returns 200).
4. User gets stuck on loading page with continuous 401 errors.

---

Expected Behavior

User should automatically join the workspace after accepting invitation and gain access to organization resources.

---

Actual Behavior

User encounters 401 Unauthorized errors for:

• GET /api/profile
• POST /api/organizations/{org_id}/workspaces/{workspace_id}/invite/accept
• POST /api/preview/tracing/spans/query
• Other workspace-related API endpoints

---

Environment

• Agenta Version: Latest OSS (self-hosted)
• Deployment Method: Docker Compose
• Platform: ARM64 EC2 instance
• Database: PostgreSQL (containerized)
• Authentication: SuperTokens

---

###Error Logs

2025-11-04T05:41:51.995Z [INFO.] [scopes] user created [oss.src.services.user_service] user_id=None
172.18.0.7:39236 - "POST /api/auth/signup HTTP/1.1" 200
2025-11-04T05:41:52.256Z [ERROR] 401: Unauthorized [oss.src.services.auth_helper]
172.18.0.7:39238 - "POST /api/organizations/.../workspaces/.../invite/accept?project_id=... HTTP/1.1" 401
2025-11-04T05:41:52.464Z [ERROR] 401: Unauthorized [oss.src.services.auth_helper]
172.18.0.7:39238 - "GET /api/profile HTTP/1.1" 401

---

Root Cause Analysis

The invitation acceptance process fails to properly associate new users with the organization in Agenta's core database. While users are successfully created in the SuperTokens authentication system, they lack the necessary organization membership records in the core database, resulting in authorization failures.

---

Impact

• Prevents scaling user invitations as manual database intervention is required for each new user.
• Breaks the standard user onboarding flow.
• Affects team collaboration features.

---

Additional Context

• First and second invited users work correctly.
• Issue appears consistently from the third user onwards.
• SuperTokens service is functioning correctly.
• Database permissions are properly configured.

---

Temporary Solution

Create this script to automatically fix new users:

#!/bin/bash

# Configuration - Update these values for your deployment
ORG_ID="019a4d38-7705-7ec2-8173-514d7cf51cba"  # Replace with your organization ID
POSTGRES_CONTAINER="agenta-oss-gh-postgres-1"

echo "Fixing new user permissions..."

# Get the most recent user who might need fixing
LATEST_USER=$(docker exec -it $POSTGRES_CONTAINER psql -U agenta_user -d agenta_oss_core -t -c "
SELECT id FROM users 
WHERE created_at > NOW() - INTERVAL '1 hour' 
ORDER BY created_at DESC 
LIMIT 1;
" | tr -d ' \n\r')

if [ -n "$LATEST_USER" ]; then
    echo "Found recent user: $LATEST_USER"
    
    # Temporarily make them organization owner to grant access
    docker exec -it $POSTGRES_CONTAINER psql -U agenta_user -d agenta_oss_core -c "
    UPDATE organizations 
    SET owner = '$LATEST_USER' 
    WHERE id = '$ORG_ID';
    "
    
    # Clean up any pending invitations for this user
    docker exec -it $POSTGRES_CONTAINER psql -U agenta_user -d agenta_oss_core -c "
    DELETE FROM project_invitations 
    WHERE organization_id = '$ORG_ID' 
    AND created_at > NOW() - INTERVAL '1 hour';
    "
    
    echo "User permissions fixed. They should now be able to access the workspace."
else
    echo "No recent users found to fix."
fi

Usage

1. Update the ORG_ID variable with your organization ID.
2. Make the script executable: chmod +x fix_new_users.sh.
3. Run after each new user signup: ./fix_new_users.sh.

Alternative Manual Fix

1. Connect to database:

docker exec -it agenta-oss-gh-postgres-1 psql -U agenta_user -d agenta_oss_core

2. Find the new user:

SELECT * FROM users ORDER BY created_at DESC LIMIT 3;

3. Make them organization owner (replace USER_ID and ORG_ID):

UPDATE organizations 
SET owner = 'NEW_USER_ID' 
WHERE id = 'YOUR_ORG_ID';

4.. Clean up invitation:

DELETE FROM project_invitations 
WHERE email = 'new_user_email@domain.com';

_AGE-3374

[dosubot]

Hi @Rohitkhapre! I'm Dosu and I’m helping the agenta team.

This bug is not yet officially tracked, but it matches several recent issues and code findings. The root cause is that invited users are created in SuperTokens but are not linked to the organization in Agenta's core database, so they get 401 errors when accessing workspace resources. The backend invitation acceptance logic (accept_organization_invitation) only marks the invitation as used—it does not actually create or associate the user with the organization or workspace in the database, which is required for authorization to work [source].

Recent changes to API route parameters and invitation link formatting (switching from org_id to organization_id) may also affect how invitations are processed and how memberships are assigned [source]. The authentication middleware expects users to have valid organization membership records in the core database; if these are missing, it will return 401 Unauthorized [source].

To resolve this, the backend needs to ensure that after signup and invitation acceptance, the user is properly added to the organization's membership records. Until this is fixed, manual database intervention (as in your workaround) is required. For more background, see related issues and workarounds discussed here and here.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}