unsloth/studio/frontend/AGENTS.md
Daniel Han f08aef1804 Studio (#4237)
* Rebuild Studio branch on top of main

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Fix security and code quality issues for Studio PR #4237

- Validate models_dir query param against allowed directory roots
  to prevent path traversal in /api/models/local endpoint
- Replace string startswith() with Path.is_relative_to() for
  frontend path traversal check in serve_frontend
- Sanitize SSE error messages to not leak exception details to
  clients (4 locations in inference.py)
- Bind port-discovery socket to 127.0.0.1 instead of all interfaces
  in llama_cpp backend
- Import datasets_root and resolve_output_dir in embedding training
  function to fix NameError and use managed output directory
- Remove stale .gitignore entries for package-lock.json and test
  directories so tests can be tracked in version control
- Add venv-reexecution logic to ui CLI command matching the studio
  command behavior

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Move models_dir path validation before try/except block

The HTTPException(403) was inside the try/except Exception handler,
so it would be caught and re-raised as a 500. Moving the validation
before the try block ensures the 403 is returned directly and also
makes the control flow clearer for static analysis (path is validated
before any filesystem operations).

* Use os.path.realpath + startswith for models_dir validation

CodeQL py/path-injection does not recognize Path.is_relative_to() as
a sanitizer. Switched to os.path.realpath + str.startswith which is
a recognized sanitizer pattern in CodeQL's taint analysis. The
startswith check uses root_str + os.sep to prevent prefix collisions
(e.g. /app/models_evil matching /app/models).

* Never pass user input to Path constructor in models_dir validation

CodeQL traces taint through Path(resolved) even after a startswith
barrier guard. Fix: the user-supplied models_dir is only used as a
string for comparison against allowed roots. The Path object passed
to _scan_models_dir comes from the trusted allowed_roots list, not
from user input. This fully breaks the taint chain.

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
2026-03-12 03:36:19 -07:00

2.1 KiB

Repository Guidelines

Project Structure & Module Organization

  • src/ is app code; entry is src/main.tsx, global styles in src/index.css.
  • src/app/ holds app shell and routing; src/features/ is feature slices w/ public index.ts exports.
  • Shared UI lives in src/components/ (shadcn in src/components/ui/).
  • Shared logic in src/hooks/, src/stores/, src/utils/, src/lib/, and types in src/types/.
  • Static assets: src/assets/ and public/.
  • test/ is a Python harness for payload validation and preview; not a JS test suite.

Build, Test, and Development Commands

  • bun run dev: start Vite dev server.
  • bun run build: typecheck + build to dist/.
  • bun run preview: serve the production build locally.
  • bun run lint: ESLint checks for TS/React.
  • bun run typecheck: tsc no-emit verification.
  • bun run biome:check / bun run biome:fix: format + lint w/ Biome.
  • Optional harness: python test/scripts/validate_payload.py test/data/ui_payload.json.

Coding Style & Naming Conventions

  • TypeScript + React, 2-space indent (Biome).
  • Prefer explicit, compact code; avoid heavy abstraction.
  • Use path alias @/ for app imports.
  • Feature boundaries enforced: import from @/features/<name> only, not deep paths.
  • Components in PascalCase, hooks in useCamelCase, files in kebab-case or camelCase per local convention.

Testing Guidelines

  • No frontend test runner configured yet; add one if needed.
  • test/ is for API payload validation and preview flows; add samples as test/data/ui_payload_*.json.

Commit & Pull Request Guidelines

  • Commit history shows short, imperative messages; optional prefix like refactor:; keep it terse.
  • PRs should include: clear summary, linked issue (if any), and UI screenshots/gifs for visual changes.
  • Call out new deps, config, or required env changes in the PR body.

Agent Notes

  • Keep changes minimal, focused, and easy to review.