Changelog

Goal for this release

Our goal this week was to finish the minimum set of features needed to put Hyper in users' hands, then stabilize the infrastructure underneath them.

We focused on four things:

• Keeping connected company knowledge up to date automatically.
• Making Hyper's work easier to follow and understand.
• Making accounts and workspaces safe for teams.
• Building a release process we can trust for regular customer updates.

We merged 39 pull requests across those areas this week.

Connected services stay up to date

Connected services can now update Hyper automatically instead of waiting for a manual or full import.

• Added webhook-based updates for Slack, Notion, GitHub, Stripe, Google Calendar, Gmail, and Drive, so changes can flow into Hyper as they happen. Google connections are renewed automatically when needed. (#102)
• Added continuous Granola updates. Because Granola does not support webhooks, Hyper checks for new and updated meetings every 15 minutes. (#103)
• Made webhook updates more precise. Hyper now imports only the page, message, issue, or record that changed instead of repeatedly importing the entire account. This makes updates faster, reduces unnecessary processing, and removes deleted information correctly. (#105)
• Simplified sync checkpoints now that individual updates are tracked directly, reducing unnecessary state in the synchronization system. (#120)
• Made Granola updates more reliable. Hyper now avoids importing the same meetings twice, retries temporary errors, respects Granola's rate limits, and only advances its checkpoint after a successful update. (#125)
• Restored the connector controls so users can connect and reconnect services and their loading, success, and error states while we design the longer-term experience. (#124)

We also finished the infrastructure needed to test this behavior safely:

• A new relay sends OAuth callbacks and webhook events to local development servers, letting us test real connector behavior before deploying it. (#126, #130)
• Notion, Slack, Stripe, and Gmail now use separate development, nightly, and stable configurations. This prevents testing from interfering with customer connections. (#131)
• Local environments can now receive webhook updates and run polling-based connectors, making local testing match the released product more closely. (#132)

Hyper can use your company's code

Hyper can now search and read connected GitHub repositories.

It can list the repositories available to a workspace, search their contents, and inspect the relevant sections of source files. This helps Hyper answer questions that require both company discussions and the implementation behind them. (#100)

We also installed the required code-search tools on our servers so this works without any setup from the user. (#106)

Hyper's GitHub access remains read-only.

Chat is easier to follow

We improved both the substance of Hyper's answers and the way its work appears in the app.

• Hyper now explains its work as it happens. Chat shows what Hyper is searching, which sources it is reading, and whether each step succeeded. These events appear at a readable pace instead of flashing by as technical logs. (#109)
• Plain language is now the default. Hyper has been instructed to give direct, concise answers and avoid unnecessary structure or jargon. (#113)
• Hyper now knows the current local time. This improves questions involving deadlines, recent events, or phrases such as "this week." (#108)
• Internal context no longer appears in chat history. Hyper still receives the account, workspace, and time information it needs, but users no longer see that internal data mixed into their messages. (#107)

Safer accounts and workspaces

We strengthened the parts of the app that keep each person's work separate.

Most desktop business logic now runs in Rust rather than inside the interface. Account and workspace changes create isolated sessions for chat, connectors, and drafts. When someone signs out or switches workspaces, Hyper closes the previous session, saves drafts, stops active work, and clears its state from the interface.

We made this change to reduce bugs where work from one account or workspace could remain visible after switching to another. It also gives us a more reliable base for the desktop app. (#88)

Additional account and workspace work includes:

• Added admin and member roles. This is the first step toward workspace creation and deletion: later changes can restrict destructive actions to admins instead of allowing every member to perform them. Existing workspaces are migrated so none are left without an admin. (#140)
• Centralized authentication across the API. Protected services now verify identity through the same shared layer, and user profiles are handled separately from login credentials. This reduces inconsistent authentication behavior as the product grows. (#144)
• Enabled the desktop app's native connection to the deployed API. This removes an important difference between local testing and the released app and gives chat and other live features a direct, secure connection. (#117)

Stable releases

Until now, we only published automatic nightly builds. This week we built the machinery required to publish deliberate, tested stable releases.

• Created separate stable and nightly channels. Each channel now has its own application configuration, update feed, database, and release storage. Stable builds are signed and can update independently from nightly builds. (#129)
• Made the release tool create the GitHub release itself. It now creates the version tag, generates notes, attaches the Mac installer, and prevents the same version from being published twice. (#136)
• Combined stable and nightly releases into one workflow. The same tested process now migrates the database, deploys the API, builds the app, signs and notarizes it, and publishes the result. This reduces the chance that the two channels drift apart. (#137)
• Added a channel-aware migration command and derived release settings from the application and server configuration. This removes duplicated settings that could silently fall out of sync. (#134)
• Automated release-server secrets. Deployments now reconcile their configuration against our central secret store, removing stale values and avoiding manual production setup. (#135)
• Updated downloads to reflect actual platform support. Hyper currently ships for Mac, so Linux visitors no longer see a download that does not exist. (#133)

Website

We prepared the public website for the new release:

• Restored missing visuals and interactions from the previous site and added a working waitlist form backed by our database. (#116)
• Fixed browser errors that prevented fonts and other assets from loading correctly, cleared all website build warnings, and improved keyboard accessibility. (#118)
• Removed links to the pricing and FAQ pages because they no longer describe the current product. (#139)

Reliability and development infrastructure

The remaining work reduces deployment risk and makes it faster to find problems before they reach users.

• Made website infrastructure deployable with one command instead of relying on interactive or manual configuration. (#122)
• Moved the download relay onto the main application host so certificates, routing, and deployment use the same managed process as our other services. (#123)
• Removed an unsafe development mode that allowed local servers to use the shared stable database. Developers now choose between a local environment and a client connected to a deployed environment. (#138)
• Pinned the Rust version used for deployments so a developer's locally installed tools cannot produce a different build from CI. (#119)
• Sped up Rust tests in CI so failures return sooner and releases spend less time waiting on repeated builds. (#121)
• Enabled stricter Rust checks and fixed roughly 185 warnings. These checks now prevent a broad class of suspicious code from being merged unnoticed. (#128)
• Added automatic TypeScript formatting so formatting problems are caught before merge and engineers do not spend review time discussing them. (#110)
• Stopped development builds from repeatedly opening macOS Keychain prompts. Local secrets are stored in a protected development file, while released builds continue using Keychain. We also removed an unnecessary failure path from that selection logic. (#111, #112)
• Shared our Claude Code frontend settings across the repository so contributors use the same design tooling. (#127)

What this release enables

Hyper now has the minimum foundation we need to begin putting the rebuilt product in front of users:

• Company knowledge can remain current without manual imports.
• Hyper can work across messages, documents, meetings, email, and code.
• Users can see what Hyper is doing and where its information comes from.
• Accounts and workspaces have stronger isolation.
• We can publish signed, versioned releases through a repeatable process.

The next step is to onboard users, watch where the product fails in daily work, and improve it through regular stable releases.