-
Notifications
You must be signed in to change notification settings - Fork 2
Projects
A project is a saved snapshot of an engagement: your rules, your captured traffic, your notes, and your findings. Projects live in ~/.joro/configs/project/ as .joro files and are portable between machines.
Joro starts in an unnamed Scratch session. Work you do there is real, but nothing is written to disk until you save it under a name. The active project is not restored across restarts — pick one when you start Joro.
Two entry points:
- The project switcher in the app header, labelled with the active project name or Scratch session. It lists your projects, and offers Save project, New project, and Manage.
- Settings → Project, which holds the full table: project name, request count, note count, file size, last saved time, the Auto-save and Save history checkboxes, and Switch and Delete actions per row. Save, New project, and Import sit above it.
Project names are barred in both while streamer mode is on, along with the names in toasts and confirmation dialogs — a client name in the header is usually the first thing a stream gives away. See Settings.
New project asks for a name and then what to do with your current session:
- Save current session snapshots everything you have right now under the new name.
- Start empty wipes live state back to a fresh baseline — no rules, default noise filter, empty history and notes — and saves that. Team server settings are kept.
If you choose Start empty while your current session has unsaved work — a scratch session, or a project with auto-save off — the dialog also offers to save it first.
Click Switch in the table, or pick a project from the header dropdown.
What happens to the session you are leaving depends on its settings. With auto-save on, it is saved silently. With auto-save off, or from an unnamed scratch session, Joro asks: Cancel, Discard & switch, or Save & switch.
After a switch, live state is rebuilt from the project you loaded. Request history and detect findings are cleared and refetched, and settings are reloaded.
Auto-save is on by default. Joro checks every 30 seconds and saves the active project when its state has actually changed, so an idle session does not rewrite the file.
Turn auto-save off for a project when you want explicit control over what gets committed to the file. Save it with the Save button in Settings → Project or Save project in the header dropdown; both write immediately regardless of the auto-save setting. Projects with auto-save off are tagged manual in the switcher.
Save history is also on by default. Turning it off omits captured request history from the file, which keeps it small — useful for a long-running engagement where the traffic volume dwarfs everything else. Note that the site map is built from captured requests, so with Save history off the site map will not persist either.
Both checkboxes take effect immediately and do not trigger a re-save.
Delete in the table's Actions column removes a project. The dialog names the project and lists what it holds — requests, notes, findings, and file size. Enter does not confirm it; the button takes a deliberate click.
Deleting removes the project's .joro, its metadata sidecar, and its testing-browser profile, so the engagement's cookies and sign-ins do not outlive it. Close the testing browser first — while the browser holds the profile open, the profile is left in place, and it stays in ~/.joro/browser-profiles/ until you remove it yourself.
Deleting the active project is allowed, and takes nothing out of your session. The file goes and the name goes, but your captured traffic, notes and findings stay exactly where they are, now an unnamed Scratch session. Save it under a new name to keep it, or switch away to discard it. Nothing is recoverable from the deleted file afterwards, so copy it out of ~/.joro/configs/project/ first if the engagement might come back.
- Scope rules and whether scope is enabled
- Noise filter patterns and whether the filter is enabled
- Match & Replace rules and Custom Data items
- Notes and history highlights
- Captured request history, subject to Save history
- Detection settings, custom rules, rule enable/disable state, severity overrides, and findings
- Team server settings: listener URL, token, and nickname
- Per-plugin state
Some things are deliberately not in the project file, because they are yours rather than the engagement's:
- Theme, hidden tabs, and dashboard layout — these live in your User Config, per operator. See Settings and Dashboard.
- Intercept toggles, which always start off.
- Automation tokens, their grants, and the MCP listener's enabled state and port. A project configuration is published to teammates, so a grant set and an auto-starting listener travelling with it would be a real privilege transfer. These live in
~/.joro/automation.jsoninstead — see Automation.
Import takes a .joro file, creates a local project from it, and loads it. Copy the file out of ~/.joro/configs/project/ to move an engagement to another workstation or hand it to someone else. Note this is the whole-project importer — the Import… button on the Scope sub-tab takes a JSON list of scope rules instead, and is described in Settings.
When connected to a team server you can also publish a project configuration to the team and let other operators load it — see Team-Server.
A .joro file is an engagement artifact. It can hold captured request history complete with session cookies and Authorization headers, the team server token, and Detect findings whose stored evidence is unredacted. It does not hold automation token secrets, which are never written to a project. The file is compressed, not encrypted.
Transport and store it the way you would any other engagement data, and delete stale copies when the engagement closes.
- Settings — the Project category holds the project browser and the rule sets a project captures
- Team-Server — publishing and loading project configurations across a team
- Testing-Browser — browser profiles are keyed on the active project, so cookies never cross engagements
- Detect — findings and custom rules are saved with the project
- Automation — capability tokens are deliberately stored outside the project file