Opening a project

Semantix Studio opens on a single button: Open Project. There's no project inside it until you point it at a folder on your machine.

A project is just a folder. There's no template, no manifest, nothing to set up first — no package.json, no .git, no particular shape. If it's a directory, it can be a project.

Choosing a folder#

The dialog gives you two ways in.

Type the path into the field and press Enter.

Or press Browse and walk your filesystem. The browser shows folders only. Single-click selects, double-click goes in, and the breadcrumb at the top takes you back up — the ~ at its left end returns you home.

While you're browsing:

• Just start typing to filter the list. Backspace edits the filter — and with the filter empty, Backspace goes up a folder. Esc clears the filter; press it again with nothing to clear and the browser closes.
• The eye toggles hidden folders. Typing a filter searches them anyway, so .config finds itself without the toggle.
• Right-click a folder for Open, Select This Folder, Add to Favorites, Copy Path and Reveal in File Manager. Favourites and the folders you've picked before live in the sidebar, so the second project is quicker than the first.
• The new folder button beside the eye starts something rather than opening it.

Once you've opened a project, it appears in the Projects menu and in this dialog's list, so coming back is one click. The remove link on a row appears on hover and only forgets the row — it never touches your files.

What happens next#

Semantix reads the project.

You'll see a thin progress bar along the top of the main area, a running message, and the same progress in the status bar at the bottom:

Indexing 1058 files...
247/1058 — content-area/ContentArea.tsx
Resolving cross-file relations...
Indexed 1058 files, 15161 symbols in 38.1s

Speed depends on your machine and what's in the project; the thousand-file example above took about forty seconds. It uses every core you have.

This happens once. Reopening a project you've already read comes straight up — it doesn't do this again. And when you edit files afterwards, only what changed is re-read; unchanged files are skipped.

What gets read, and what doesn't#

Everything that isn't obviously noise. Semantix skips, always:

.git · .svn · .hg · .vscode · .idea · .claude · .semantix · node_modules · dist · build · out · .next · .nuxt · .turbo · .cache · coverage · target · __pycache__ · .venv · venv · .pytest_cache · .mypy_cache · .ruff_cache · vendor

…plus everything beginning with a dot, and everything your .gitignore excludes — including your global gitignore and .git/info/exclude. The list is deliberately short; anything debatable belongs in your .gitignore, where you already decided it.

There is no file-type whitelist and no size limit. Every file that survives those rules appears in your tree and is findable by name, whatever it is.

What differs is depth. Eight languages get read properly — every function, class and constant, and which of them reach for which:

Rust · TypeScript · TSX · JavaScript (with JSX) · Python · Go · HTML · CSS

Everything else is present and openable, but has no symbols. That's why hovering a name in a .rb or .java file tells you nothing, and why those files never appear under Symbols in search.

Where Semantix keeps things#

Nothing is written inside your project folder. Everything lives under ~/.semantix. The parts worth knowing about:

~/.semantix/
├── projects.json          your project list
├── conversations.db       every conversation, all projects
├── analytics.db           your usage statistics
├── extensions/            installed extensions
├── USER/                  sign-in, settings, instructions, saved commands, models
└── WORKSPACE/<project>/
    ├── settings.json      this project's settings
    ├── instructions/      this project's instructions
    ├── commands/          this project's saved commands
    ├── checkpoints/       the snapshots the agent's Restore rolls back to
    └── index/             what Semantix learned about your code — and, in its own
                           file, your open tabs, panel sizes and fonts

Worth backing up: USER/, conversations.db, projects.json, analytics.db, extensions/, and each WORKSPACE/<project>/.

Safe to delete: the code index — Semantix rebuilds it, at the cost of one read of the project. Re-indexing from Settings does exactly that and leaves everything else alone.

Coming back#

Reopen a project and you get your open tabs and the active one, your explorer's unfolded folders, your scroll position in each file, your panel sizes, fonts and editor theme, your keybindings, and your conversations.

Switching projects reloads the window and starts clean, the way switching folders in any editor does.

Changes made while Semantix was closed#

While Semantix is open, it watches your project — files you change in another editor show up here, and files it creates appear in your tree without a refresh.

While it's closed, it isn't watching. If you git pull, switch branches, or edit files in another editor with Semantix shut, it comes back knowing the project as it was. New files are missing; deleted files are still listed, in the tree and in search, until you tell it otherwise.

The fix is Settings → General → Re-index project, which reads the whole project again and reports how many files it indexed. It's worth reaching for after any big change made behind its back.

→ The explorer · Search