Skip to main content

​
Changelog

User-facing changes only, summarised. One entry per day.
​
Missions ship as a repeatable way to keep catalogs, scenarios, and product checks up to date.

​
Missions and collection sync

  • Missions. Qodex can now save repeatable product-quality jobs with a goal, instructions, parameters, run history, and impact stats.
  • Run now. Users can start a mission manually when they need immediate work after an import, merge, or product change.
  • Collection sync. Qodex can run a full first sync to establish a catalog baseline, then focus later syncs on changed API routes and request shapes.
  • Preset catalog. Teams can start from mission presets instead of writing every mission from scratch.
See Missions, Endpoint catalog, and API scenarios.
​
PR review commands and learned review context become clearer from GitHub.

​
PR review learning and commands

  • Command acknowledgements. Qodex now acknowledges supported PR commands and replies when a command needs user attention.
  • Bare mention help. A simple @qodex-ai mention can show the current command help in the PR thread.
  • Learned PR context. PR review can use project-specific lessons from earlier resolved findings and reviewer feedback, and explains when no learned context exists yet.
See PR review and Slash commands.
​
Sign-in and auth-profile setup get easier for teams using multiple identities.

​
Sign-in and auth profiles

  • Google and GitHub sign-in. Users can sign in with Google, GitHub, or email.
  • Auth-profile token check. API auth profiles can mint and test a token from the profile card before a scenario or Playground request depends on it.
  • Clearer token parameters. Token request settings are easier to fill out when a profile needs specific OAuth or login parameters.
See Members and roles and Auth profiles.
​
PR review supports monorepos and gives teams more control over which branches are reviewed.

​
Monorepo PR review

  • Repo folder scoping. The same GitHub repo can be linked once per project directory, so monorepos can keep separate Qodex projects for separate apps or services.
  • Base-branch controls. Teams can choose which base branches should receive Qodex reviews.
  • Affected route context. PR review can show which application routes are affected by a change, helping teams understand review scope.
See Connect a repo and PR review.
​
Knowledge becomes easier to browse, import, read, and edit inside Qodex.

​
Knowledge Drive

  • Knowledge browser. The Knowledge tab now has a folder-style browser for project notes and memory files.
  • Document import. Users can import documents into project knowledge so Qodex can use them as testing context.
  • Read and edit knowledge files. Knowledge files can be inspected and updated without leaving the Knowledge tab.
See Memory and Memory concept overview.
​
Test run results become easier to share and easier to triage.

​
Run reports and failure summaries

  • Plain-English failure summaries. Failed runs can explain the likely reason for the failure before users dig into step artifacts.
  • Downloadable HTML reports. Test run details can export a self-contained report for sharing with teammates or release owners.
  • Direct report links. Report emails can take users straight to the downloadable result.
See Run tests and Findings.
​
API scenario evidence becomes easier to inspect after a save or run.

​
API step evidence

  • Expandable API step detail. API steps can show request data, captured examples, and file downloads in the scenario detail surface.
  • Captured request and response samples. Qodex can save useful per-step examples so users can understand what a scenario actually sent and received.
  • Step file downloads. Uploaded request files and CSV data files can be downloaded from the relevant scenario surfaces.
See API scenarios and Request data generation.
​
API debugging gets clearer variables, and Qodex can test email-dependent flows.

​
Playground variables and email testing

  • Path-variable rows. API Playground requests can expose path variables as editable rows, including colon-style params such as :userId.
  • Unresolved variable warnings. Playground and runs surface unresolved variables so users can add the value to the environment before relying on the request.
  • Project inbox. Each project can have an inbound email address for testing flows that send email.
  • Email wait step. Scenarios can wait for a matching email before continuing, which helps with invite, reset-password, and verification flows.
See API Playground and Scenarios.
​
File-upload scenarios and project login protection ship.

​
Upload testing and project sign-in checks

  • API multipart uploads. API scenarios can include multipart file upload steps.
  • UI upload replay. UI scenarios can record and replay file-upload actions.
  • Project-level email code. Projects can require an extra email code during sign-in.
See API scenarios, UI testing, and Members and roles.
​
The Chrome recorder can save signed-in browser flows more naturally.

​
Recorder and collection updates

  • Include login in recordings. The Chrome recorder can capture signed-in manual flows and save them as draft UI scenarios.
  • Collection rename from chat. Qodex can rename API collections from chat when a collection needs a clearer name.
See UI testing and Endpoint catalog.
​
The marketing site can collect public scan requests and route them into Qodex.

​
Public scan request intake

  • Public scan-request form. The qodex.ai website can now accept scan requests from visitors for follow-up.
​
The Chrome recorder can capture richer UI flows and use the browser to reach localhost targets.

​
Chrome recorder

  • Record UI flows from Chrome. The Qodex Chrome recorder can capture browser actions and save them as draft UI scenarios.
  • Localhost browser proxy. Browser-side requests can reach localhost targets that the hosted runner cannot access directly.
See UI testing, Intent-driven UI scenarios, and API Playground.
​
Scenarios gain dynamic values, and auth-profile tokens get easier to inspect.

​
Dynamic scenario values and auth helpers

  • Dynamic run-time values. Scenarios can now use built-in tokens for timestamps, UUIDs, random strings, random emails, and run-stable values that stay the same across one run.
  • Dynamic values in UI replay. UI scenarios can resolve those same dynamic tokens during replay, which helps recorded or generated flows avoid stale unique values.
  • Auth-profile token copy. Auth profile cards can reveal and copy the cached bearer token when a user needs to inspect or debug how a profile is being used.
See Scenarios and Auth profiles.
​
Scenario folders gain a second level, imports handle more collection shapes, and uploads get larger.

​
Nested folders and imports

  • Two-level scenario folders. Scenario groups can now include one nested folder level, so teams can organize a large test area into smaller sub-flows without creating separate top-level groups.
  • More flexible collection imports. Imported collections that do not define a host can fall back to the project default environment instead of forcing users to repair the collection first.
  • Larger chat uploads. Chat attachments now support files up to 50 MB, making larger specs, collections, and supporting files easier to share with Qodex.
See Test groups and folders, Import an OpenAPI spec, and Import a Postman collection.
​
Collection import moves into chat.

​
Collection import through chat

  • Import collections through chat. Qodex can now start an API collection import from the chat composer, so users can upload a collection and keep the import flow in the same conversation where they ask questions.
See Import an OpenAPI spec and Import a Postman collection.
​
Collection rename and email-verification login ship.

​
Collection rename and email verification

  • Rename collections from settings. Collections can be renamed from the collection settings modal, so teams can keep imported API catalogs readable as projects change.
  • Email verification login. Verification links can take users straight into an authenticated session after they confirm their email.
See API Playground, Scenarios, and Account workspaces and projects.
​
Pull request review gets clearer table controls and repo-specific settings.

​
PR review controls

  • PR table review controls. The Pull Requests page can show review state per row and lets users run a review from the table.
  • Repo-specific review policy. Teams can tune review context, author allowlists, and review settings per repo.
See PR review, Walkthrough anatomy, and .qodex.yaml reference.
​
PR review comments and review settings become easier to control.

​
PR review comments and settings

  • Cleaner PR comments. Reviews now favor crisp comments, one persistent walkthrough, deduplicated content, and comments that can resolve when the underlying issue is fixed.
  • Editable review context. Teams can add repository context and review preferences so Qodex reviews the project with the right expectations.
See PR review, Inline findings, and .qodex.yaml reference.
​
Scenarios gain better support for async systems and uploaded-file context.

​
Scenario timing and file context

  • Per-step delays. Scenario steps can include a deliberate delay when the system needs time for asynchronous backend work before the next assertion.
  • File-aware chat context. Uploaded file contents can be injected into a chat turn, so Qodex can use the file as direct context when creating or refining tests.
See Scenarios and API testing scenarios.
​
Conditional scenario steps and richer UI testing support land.

​
Conditional steps and UI testing depth

  • Conditional scenario steps. Scenarios can use a when guard so a step runs only when the previous data, state, or environment makes that step relevant.
  • Nested dropdown handling. UI testing can surface nested dropdown options during authoring and replay, making complex menus easier to test.
  • Live browser wall. UI test authoring and replay can show the browser activity more clearly while Qodex explores or verifies a flow.
See Scenarios, Intent-driven UI scenarios, and Replay cache and self-healing.
​
Team invites become easier to complete.
  • Invite by link. Project members can join from an invite link, so a team can onboard someone even when email delivery is delayed or blocked.
See Members and roles.
​
Scenario repair gets safer recovery.

​
Scenario recovery

  • Scenario snapshot and rollback. Qodex can snapshot a scenario before an automated repair and roll back if the repair cannot complete cleanly.
See Scenarios.
​
Scenario groups become easier to use, and UI test artifacts improve.

​
Scenario groups and run artifacts

  • Groups default to parallel. New scenario groups now start in parallel mode, which matches the common folder-style use case for independent scenarios.
  • “Scenarios” language replaces “members.” Group management now talks about scenarios, including Manage scenarios, scenario counts, and Add to group.
  • Record UI-only groups. UI-only scenario groups can be run with video recording, giving every UI scenario in the group a replay artifact.
  • Screenshot lightbox. Test run details can open step screenshots in a larger lightbox for easier debugging.
See Test groups and folders and Per-step artifacts.
​
Scenario groups and folders land with sequential and parallel execution modes.

​
Test groups and folders

  • Scenario groups as runnable folders. Teams can organize related scenarios into groups and run the group as one unit from the web app, schedules, webhooks, CI, or the full suite.
  • Sequential and parallel modes. Sequential groups run scenarios in order and can share captured values. Parallel groups run independent scenarios at the same time.
  • Add to group. Selected scenarios can be added to a group from the scenario list, with validation for sequential and parallel membership rules.
  • Scenario groups view. The groups tab shows group ids such as TG-001, scenario counts, parallel badges, searchable groups, and scenarios inside each group.
  • Drag to reorder. Scenarios inside a group can be reordered directly in the group tree or detail view.
  • Grouped results. Test run details show grouped scenarios under their group container, including a parallel indicator when relevant.
See Test groups and folders and Run the full suite.
​
UI auth profiles support browser-session import and authoring-time reuse.

​
UI auth profiles

  • UI auth profiles. Browser sessions can now be saved as UI auth profiles and injected into UI scenario replay, so scenarios can start already authenticated.
  • Session import for hard logins. For captcha, OTP, SSO, or other logins the agent cannot automate, users can import a browser session and bind it to an auth profile.
  • Authoring with a bound profile. UI scenario authoring can start from a saved profile’s session instead of forcing the agent through login steps every time.
See Auth profiles and Intent-driven UI scenarios.
​
Pull request reviews can be retried from the Pull Requests page.

​
Pull request review retry

  • Retry failed PR reviews. The Pull Requests page now exposes a retry path for failed reviews.
See PR review troubleshooting.
​
Onboarding and GitHub PR-review setup become more guided.

​
Onboarding and PR-review setup

  • Attach-first onboarding. The onboarding flow now guides users toward attaching a Codex account earlier.
  • Simpler setup steps. The wizard drops the API/web/both question and uses a clearer step sequence.
  • Auto-review after GitHub connect. GitHub PR-review onboarding can trigger a review on connect so new users see value immediately.
  • Auto-named Codex accounts. Attached Codex accounts can be named after the person adding them.
See Connect a repo and Account workspaces and projects.
​
Plans, pull request tables, and Codex account health get clearer product surfaces.

​
Plans, PR tables, and Codex account health

  • Plan entitlements. Qodex now shows plan limits, module access, usage caps, and upgrade-request state from one consistent model.
  • Pull Requests table parity. The Pull Requests table now matches the Scenarios table structure and filtering model.
  • OAuth expiry emails. Users receive email alerts when a Codex account’s OAuth authorization expires.
See Plans and pricing, Usage and cost caps, and Pull requests.
​
PR review gets smarter slash commands and more configurable review policy.

​
PR review commands and configuration

  • Cleaner repeated reviews. Qodex avoids repeating review comments the team has already handled in the PR discussion.
  • PR description quality signal. The review checklist can call out when a PR description does not give enough context.
  • Per-rule disable support. .qodex.yaml can now disable specific review rules with disabled_rules, so teams can turn off checks that do not fit a repo.
  • @qodex retry and @qodex fix. @qodex retry works as an alias for @qodex review, and @qodex fix can suggest a focused fix from an inline finding.
See Slash commands, .qodex.yaml reference, and Inline findings.
​
PR review gets manual re-runs, duplicate suppression, walkthrough tables, and triage commands.

​
PR review workflow improvements

  • Manual review trigger. Users can manually trigger PR reviews, and repeated triggers on the same SHA reuse recent or running reviews instead of creating duplicate jobs.
  • Incremental review and carry-over. Qodex suppresses duplicate inline comments across review runs, carries findings forward safely, and avoids hard-filtering findings against a truncated incremental diff.
  • Walkthrough table. Review comments now include a per-file walkthrough table so readers can see what changed and where Qodex focused.
  • Slash-command triage. @qodex resolve and @qodex ignore landed for review workflows.
See Walkthrough comment anatomy, Troubleshooting PR review, and How a review fires.
​
Transparency block lands at the bottom of every PR review walkthrough.

​
Transparency block on every walkthrough

  • Every PR review walkthrough now ends with a “What Qodex checked” block: rules applied, files reviewed, findings dropped by post-filter, probe outcomes per verified finding.
  • On by default. The severity_threshold and confidence_floor reported in the block come straight from the repo’s .qodex.yaml.
  • Intent: decide in one glance whether to trust the review or read the diff yourself.
See Walkthrough comment anatomy and How a review fires.
​
M1 PR review surface ships end to end: webhook, walkthrough, inline comments, verification probes, .qodex.yaml, slash commands, Check Run, multi-project routing.

​
M1 PR review ships

  • Reviews fire on every PR. pull_request events (opened, synchronize, reopened) trigger a top-level walkthrough comment plus inline comments on findings inside the diff. Findings outside the diff fall back into the walkthrough body so nothing is dropped silently. See PR review and How a review fires.
  • .qodex.yaml per-repo config. Each linked repo can set severity_threshold, confidence_floor, path includes and excludes, and advisory vs blocking mode. Read off the PR head SHA, so config changes ship with the PR. Invalid YAML is reported as an inline comment on the file, not silently ignored. See .qodex.yaml reference.
  • Slash commands. @qodex review re-runs the walkthrough and inline findings on the current head SHA. @qodex help posts the supported-command list. Permissions inherited from the GitHub App install. Author must be a repo collaborator. See Slash commands.
  • Pre-merge Check Run. Every review creates a GitHub Check Run that starts in in_progress on webhook receipt and ends in neutral (advisory, default), success, or failure (blocking, opt-in via .qodex.yaml). Branch protection can require qodex/review. See Check Run and merge gating.
  • Verification probes against preview deployments. When a PR has a successful preview, the reviewer emits one or more HTTP probes per finding, runs them against the preview URL, and attaches request line + response status + verdict (verified, unverified, inconclusive) as evidence. SSRF allowlist rejects link-local, loopback, private, and reserved ranges. See Verification probes.
  • Multi-project install routing. One GitHub App install can now serve many projects through a project_installs grant table. Connecting a new project to an already-installed org is one click, not a re-install. Existing single-project installs auto-backfilled. See Multi-project routing and Connect a repo.