One React client ships to browsers and Electron desktops
OCTO Web is the user-facing client for a broader workplace system. The same React application runs in a browser and inside an Electron shell, with platform branches reserved for native capabilities such as tray behavior, notifications, file dropping, and updates. Its main screens cover chats, channels, organizations, settings, files, and agent interactions. Streaming replies, tool-call previews, identity labels, and read receipts treat AI participants as ordinary parts of a conversation rather than a separate chatbot page.
The repository is far larger than the name suggests. Our checkout contained 3,447 files, about 354,079 source lines, and 41.4 MB before installed dependencies. It is a pnpm workspace monorepo with packages for several product areas, not one small Vite application. English and Simplified Chinese resources ship together, while the README and main project explanation are available in English. Apache-2.0 licensing permits internal modification and redistribution under its terms.
The client requires OCTO Server on port 8080
The quick start runs the front end, but a useful session depends on a separate backend. By default, the browser expects octo-server at http://localhost:8080 over REST and WebSocket. A local environment file changes the VITE_API_* values. That means a successful development server is only the shell of the product; login, messages, presence, files, and agents need compatible server behavior and data behind it.
The README maps 9 repositories across web, Android, iOS, server, tasks, summaries, administration, shared Go code, and adapters. A team adopting the complete workplace must version those parts together and understand which service owns a failure. The web client alone does not provide accounts, storage, or agent execution. Electron adds another release path for macOS, Windows, and Linux, so desktop signing, updates, and native packaging sit beyond the browser build.
What happened when we ran it
Our sandbox installed 1,870 packages in 92 seconds, leaving 1,178 MB on disk. The build then failed with exit code 1 after 8 seconds. Its tail named @octo/web#build, reported 0 successful tasks out of 2, and ended in pnpm lifecycle errors. The repository had 23 CI workflow files and a Dockerfile, which shows substantial automation exists, but neither signal changes the result from commit aead41c on our clean machine.
Tests failed with exit code 1 after 10 seconds. The summary listed failing commands for @octo/base, @octo/web, @octo/contacts, @octo/mail, @octo/datasource, @octo/login, @dmwork/mcp, @dmwork/summary, and @dmwork/skillmarket. The supplied tail does not include the earlier errors that triggered those lifecycle failures, so assigning a root cause would be guesswork. The defensible finding is that neither top-level quality command passed in the stated sandbox.
The package metadata accepts Node 18 or newer and pins pnpm 10.32.0. Curiously, the build tail printed Node 18.20.8 although the supplied sandbox image was lab-node:22. That observation is not an explanation for the failure. A prospective contributor should first capture the resolved Node and pnpm paths, then rerun the failing workspace command with its full log. With 1,870 installed packages, toolchain drift and workspace-specific scripts deserve explicit checks.
Drive folders stop at 200 items pending server work
Open issue 1325 documents a practical limit in the cloud-drive interface. The current behavior makes one fetch with a page size of 200 and tells users when the displayed set is truncated. Completing infinite scrolling depends on a new backend ordering contract and index, not only a React hook. The issue also describes races among reload, load-more, retry, filter, and context changes. Organizations planning large shared directories should treat full browsing as unfinished until both client and server changes land.
Another open report, issue 1312, says zip uploads fail and leave a red failure card with a truncated filename. Issue 1313 asks for image previews to remain in the site instead of opening a new tab and to support galleries. These reports are specific rather than fatal, but they expose how much product surface the client carries. Messaging may be the center, yet file transfer and preview behavior will influence whether users can replace their existing workplace tool.
August 2026 activity is high, while stability is still moving
Version 1.14.0 was published on August 24, 2026, and the repository was pushed again on August 26. GitHub reported 884 stars and 72 combined open issues and pull requests. The release includes desktop packaging fixes, settings work, mail changes, summary-contract updates, chat behavior, voice input, and test infrastructure. That volume shows active engineering. It also means adopters should expect contracts and product details to change across several modules at once.
OCTO Web makes the most sense as one part of an OCTO decision, never as an isolated React component. The dual browser and desktop codebase avoids maintaining two front ends, and the agent conversation model is more integrated than a bolt-on assistant panel. Our failed build and broad test failure keep it out of the low-risk category. Prove the exact server revision, toolchain, login flow, message path, and file workflow on your infrastructure before asking users to depend on it.