---
name: access-troubleshooting
description: Use when debugging Remix access, missing visibility, membership confusion, cwd-derived scope issues, or why a user can read an app but not its project or organization.
---

# Access Troubleshooting

Use this skill when the question is why access works, fails, or only partially works in Remix.

This skill is about access diagnosis, not the full collaboration workflow.

Mental model:

- App visibility is not the same thing as project or organization visibility.
- A readable app can still have an unreadable project or organization.
- Partial success with warnings is often the correct outcome for app-scoped diagnostics.

Recommended sequence:

1. Start with `remix_access_debug`.
2. In a bound repo, prefer `scope=app` first unless the user explicitly asked about project or organization access.
3. Use `access.appContext` and `access.effectiveAppAccess` to explain:
   - how the app is visible,
   - whether access is direct app membership or inherited project membership,
   - whether project or organization context is intentionally unreadable.
4. Only use project or organization scope when the question is explicitly about those scopes, or when an explicit id is provided.
5. Use invite and member tools only after the scope is clear and the access path has been explained.

Important rules:

- Do not assume app visibility implies project visibility.
- Do not treat unreadable project or organization context from an app-readable repo as a broken state by default.
- Do not start access debugging from a bound repo with project or organization tools first.
- If `scope=app` succeeds with warnings, use those warnings as part of the explanation rather than escalating immediately.
- If explicit project or organization scope fails, report that as a real boundary for that scope, not as an app-level failure.
