{"slug": "show-hn-an-open-source-workspace-for-your-agents", "title": "Show HN: An open-source workspace for your agents", "summary": "Gigeey released Launchpad Studio, an open-source, local-first desktop workspace for macOS that lets users build a team of specialized AI agents with individual instructions, skills, memory, and model providers, enabling delegation, scheduled tasks, and learning from use. The app, available as a signed and notarized .dmg or from source, requires Rust, Node.js 20.19+, and about 9 GB of disk space, and supports any model provider without lock-in.", "body_md": "**Build Your Team...without hiring one.**\n\nA local-first desktop workspace where you build a team of specialized AI agents that\ndelegate to each other, work on their own schedule, and get better every time you use them.\n\n[Download](https://github.com/gigeey/launchpad-studio-releases/releases/latest) ·\n[Quick start](#quick-start) ·\n[What it contacts](#what-the-app-contacts) ·\n[Security](#security--permissions) ·\n[How it works](#the-autonomy-ladder) ·\n[Docs](#documentation) ·\n[Architecture](#architecture) ·\n[Issues](https://github.com/gigeey/launchpad-studio/issues) ·\n[gigeey.com](https://www.gigeey.com/)\n\nMost agent tools give you one chat window and one model. Launchpad Studio gives you an\n**org**: a roster of specialized agents — a Frontend, a Backend, a Debugger, a Reviewer —\neach with its own instructions, skills, memory, and model, that hand work to one another,\npick tasks up on a schedule without being asked, and **compound what they learn** so your\nhands-on time trends toward zero.\n\nIt runs on your machine, talks to any model provider you point it at, and is built to keep your token bill sane: put an expensive, capable model in the coordinator's seat and delegate the grunt work to cheaper ones — or flip it, and let a cheap coordinator consult a stronger specialist only when it needs to. We built Launchpad Studio this way, and it's how we shipped it.\n\nAn org, not a chat window | Compose specialized agents with their own persona, instructions, skills, memory, tools, and model. Agents delegate to each other through address books — and every agent can itself be a coordinator. |\nMix and match models | Provider and model live per agent. Run a strong model where the thinking is, cheap models where the grunt work is. No lock-in — swap providers per agent. |\nWorks while you don't | Assignments run agents on a schedule (cron), on a webhook, or when a connected data source changes — so the same agent you chat with can also review every PR overnight, applying your preferences. |\nHands off whole goals | Projects let you hand over an objective. The agent interviews you to capture intent, drives itself with tasklists, and is gated by an independent verifier that checks the work against the goal before it can call the job done. |\nGets better with use | Agents observe their own work, distill reusable skills and memories from it, and surface them to you for a one-click accept. Every session leaves the org a little sharper. |\nLocal-first & extensible | Your data stays on your machine. Extend agents with Skills, Plugins, and MCP Connectors, and codify repeatable processes as multi-phase Workflows. |\n\n**Download it** — [ Launchpad_Studio_universal.dmg](https://github.com/gigeey/launchpad-studio-releases/releases/latest/download/Launchpad_Studio_universal.dmg)\nfrom the\n\n[releases repository](https://github.com/gigeey/launchpad-studio-releases/releases/latest). One universal build covers Apple silicon and Intel, and it is signed and notarized, so it opens with a normal double-click.\n\n**macOS only**— the release manifest lists\n\n`darwin-aarch64`\n\nand\n`darwin-x86_64`\n\nand nothing else.The packaging and release tooling is *not* in this repository, so that exact `.dmg`\n\ncannot be\nreproduced from this tree. Build from source if you want a binary you built yourself.\n\n**Or build from source.** Read [platform support](#platform-support-and-known-limitations) first\nif you are not on macOS.\n\n**Prerequisites:** Rust (stable), Node.js 20.19+ / 22.13+ / 24+, a C compiler toolchain, and\nabout **9 GB of free disk** for the first Rust build. `npm install`\n\nchecks the Node version and\nstops if it is too old. [guide/DEVELOPING.md](/gigeey/launchpad-studio/blob/main/guide/DEVELOPING.md) has the reason behind each\nrequirement.\n\n```\ngit clone https://github.com/gigeey/launchpad-studio.git\ncd launchpad-studio/frontend\nnpm install\nnpm run tauri dev\n```\n\nTwo routes, and the first one needs **no API key at all**.\n\n**If you already have an agent CLI, you are done.** Agents run in **CLI mode by default**:\nLaunchpad drives an existing CLI as a subprocess each turn and normalizes its output, so that\nCLI's own login is the credential. Nothing to paste, nothing to bill separately. When you create\nan agent, the app probes your `PATH`\n\nand marks which of these it found:\n\n| CLI | Command |\n|---|---|\n| Claude | `claude` |\n| Cursor | `cursor-agent` |\n| Codex | `codex` |\n| Antigravity | `agy` |\n\nPick the one you have and its command and arguments are filled in for you.\n\nMost of the day-to-day development and testing has been against the Claude CLI.The other three have their own output normalizers and do work, but they are less exercised — expect rougher edges, and please open an issue when you hit one. The differences that are already known are about where each CLI will accept MCP configuration, and they are written up at the functions that handle them in`crates/ao-engine/src/agent_runner/cli.rs`\n\n: Claude and Codex take per-invocation config, while`cursor-agent`\n\nand`agy`\n\nhave no such flag, so Launchpad has to merge its entry into a config file they share across sessions.\n\n**Otherwise, use a provider API key.** Set an agent's kind to **Native (API)** and it runs an\nin-process client instead of spawning anything. Three providers are wired to that path —\n**Anthropic, OpenAI, and OpenRouter**. The usual way is in the app: create the agent, pick a\nprovider, paste the key. It is stored in your OS keychain, not in the repository.\n\n`providers.toml.example`\n\nalso has a commented-out`[gemini]`\n\nsection, and a key set there is accepted and stored.Nothing consumes it— there is no Gemini variant on the native provider enum, so no agent can be pointed at it. See[KNOWN-GAPS.md].\n\nFor a headless or CI setup with no UI to click, the same credentials can be provisioned from a file. Copy the example into your data directory — not the repository root, which the app never reads — and uncomment the provider you use:\n\n```\nmkdir -p ~/.launchpad_studio\ncp providers.toml.example ~/.launchpad_studio/providers.toml\n```\n\nThe directory is `~/.launchpad_studio`\n\nunless you point it elsewhere — see\n[workspaces](#workspaces--more-than-one-org). [ providers.toml.example](/gigeey/launchpad-studio/blob/main/providers.toml.example)\ndocuments every accepted field, and explains why your key disappears from the file after the\nfirst run (it is moved into the keychain).\n\nCreate your first agent, pick its model, and start chatting. From there, give it an address\nbook, hand it a tasklist, or set it an assignment — and start climbing\n[the ladder](#the-autonomy-ladder).\n\nThree requests leave your machine without you asking for them — two of them if you built from this repository, because the updater does not run in a source build. None of them carry anything about you, your agents, or your work — but a tool that runs agents on your own machine should say what it talks to.\n\n**A version check**, once per launch, with a three-second timeout. It reads`latest.json`\n\nfrom the public releases repository and caches the answer in`localStorage`\n\n(`fetchLatestVersion()`\n\nin`frontend/src/utils/versionCheck.ts`\n\n).**The updater**, in a release build only: a first check five seconds after launch, then one every four hours, against that same file through Tauri's updater plugin (`startUpdateMonitor()`\n\nin`frontend/src/stores/updateStore.ts`\n\n; the endpoint is the`plugins.updater.endpoints`\n\nentry in`frontend/src-tauri/tauri.conf.json`\n\n). A build from this repository never starts it —`frontend/src/main.tsx`\n\nguards the call on`import.meta.env.DEV`\n\n— because installing a signed release bundle over the build you are editing is never the right action, and the remedy for a stale checkout is`git pull`\n\n.**It only works on macOS.** The published manifest lists`darwin-aarch64`\n\nand`darwin-x86_64`\n\nand nothing else, and the plugin looks for an artifact matching the running target before it compares versions — so on Linux and Windows every check fails with`TargetsNotFound`\n\n, whether or not a newer version exists. That failure is logged to the console and deliberately not shown in the UI, because it is not a state the reader can act on. The version check in the bullet above is unaffected: it runs in both build types, on every platform.**A connectivity probe**, every ten seconds, to`https://www.google.com/generate_204`\n\n. This is what drives the online/offline indicator in the UI (`INTERNET_CHECK_URL`\n\nin`frontend/src/stores/networkStore.ts`\n\n).\n\nThere is no setting that turns any of them off. Removing them means removing those three call sites. Your prompts, agents, and files go only to the model provider you configure.\n\n**The version check can lock a source build out of the app** — see\n[known limitations](#platform-support-and-known-limitations).\n\nAn agent here runs real tools on your machine, under your user account, with your privileges. That is the point of the product and it is also the thing to understand before you hand one a schedule.\n\n**Two independent gates decide whether a tool call runs.** The session posture (`PermissionMode`\n\nin`crates/ao-engine-tools-core/src/permissions.rs`\n\n) is one of`Default`\n\n— consult tool decisions, hooks, and the approval bridge —`Plan`\n\n, where read-only tools may run and everything else is denied so the model can draft without touching anything, or`BypassPermissions`\n\n, which short-circuits every gate and exists for trusted automation. On top of that, each tool returns its own decision, and anything that answers`Ask`\n\nraises a prompt.**Shell commands skip the prompt only from an allowlist.**`bash`\n\n's auto-approval gate (`crates/ao-engine-tools-io/src/bash/auto_approve.rs`\n\n) is deliberately not a shell parser: it rejects command substitution, process substitution, output redirection, sequencing operators, background control, multi-line scripts, and any command not explicitly listed. Asking when it could have allowed costs you a click; allowing when it should have asked is the bug the module exists to prevent, so it rejects when in doubt.**Unattended runs deny by default.** In an autonomous session — an assignment firing on cron, a webhook, a connector event — no one is at the keyboard to answer a dialog. Rather than assume consent, an`Ask`\n\nbecomes an auto-**deny** with a recoverable error the model can adapt to, unless a per-launch auto-approve rule matches it — the`PermissionDecision::Ask`\n\narm in`crates/ao-engine-tools-runner/src/permissions/mod.rs`\n\n.**Nothing the agent writes about itself goes live unreviewed.** Distilled skills and cross-scope memory writes pass a staging gate (`crates/ao-engine-tools-core/src/trust_gate/mod.rs`\n\n) that stages them for your approval, and overwriting anything you authored yourself is a hard block, never an automatic action.**Credentials live in the OS keychain**, not in the repository or in plain config. Your data — profiles, threads, memories, assignments — lives in`~/.launchpad_studio`\n\n(or`LAUNCHPAD_STUDIO_DATA_DIR`\n\n).\n\nFound a vulnerability? Please do not open an issue — [SECURITY.md](/gigeey/launchpad-studio/blob/main/SECURITY.md) describes the\nprivate reporting channel.\n\nLaunchpad Studio is designed so you can hand over as little or as much as you trust an agent with — and climb that ladder over time. Each rung does more on its own than the last.\n\nAn **agent profile** is a specialist you shape once and reuse. It carries a persona and\nspecial instructions, a curated set of skills and tools, its own memory, and its own model\nand provider. That's how you get a Frontend agent that thinks in components, a Backend agent\nthat knows your services, and a Debugger that's relentless — instead of one generalist you\nhave to re-brief every time.\n\nYou work with agents through a **chat-style interface** that feels familiar, but without the\nclassic context-window headache. Each agent supports multiple parallel **threads** (a default\nthread, plus fresh or branched ones), and each thread keeps a **working-window anchor** that\ntrims stale content out of the live prompt *per thread* — so a long-running conversation\ndoesn't collapse into one lossy compaction. Knowledge that's about to scroll out of the\nwindow is captured first (see [the compounding layer](#the-compounding-layer)) rather than\nsummarized away.\n\nEvery agent has an **address book** — a curated list of other agents it's allowed to delegate\nto, each with a stated purpose. When an agent hands off work with the **Delegate** action, it\ncan only reach targets in its book (it can't invent one), and it can pass the handoff either\nsynchronously (wait for the result) or asynchronously (fire and check back later). Delegation\ntargets can optionally see an excerpt of the coordinator's conversation, so a specialist\nisn't working blind.\n\nBecause provider and model are per-agent, address books are also your **cost dial**:\n\n**Strong coordinator, cheap workers**— an expensive model plans and reviews, delegating the repetitive work to cheaper agents.** Cheap coordinator, strong specialist**— an inexpensive model runs the show and only consults a premium model for the hard calls.\n\nBoth patterns work; we used both. Cycle safety (no self-delegation, a runtime depth cap) keeps deep delegation graphs from running away while still allowing legitimate back-and-forth and fan-out topologies.\n\nWhen work is genuinely multi-step, a single ballooning conversation is the wrong tool.\nA **tasklist** breaks the work into discrete steps and spins up a **fresh, clean agent\ninstance for each one** — every step gets a focused context and a single objective, instead of\none run accumulating the whole history. (If you've ever hand-rolled a \"keep looping until\ndone\" prompt, this is the structured replacement for it.)\n\n**Two ways to create one.** You can build a tasklist yourself from the chat's Todos tab, or an agent can create one automatically (via its`TodoCreate`\n\ntool) the moment it recognizes multi-step work.**Automatic routing.** A per-agent \"mini coordinator\" assigns each unowned step to the best-fit agent from the owner's address book, reading each delegate's stated purpose to route it. An agent with an empty book just keeps the work in-house.**Sequential or parallel**, and non-blocking — you can keep chatting with the agent while its tasklist runs, with each step's output isolated to its own channel so it never floods the main chat.**Reviewable.** Every step records its status, a summary, and its output to a shared workspace, so later steps can build on earlier ones and you can review the finished result step by step.\n\nA **project** is for a long-running goal with a definite finish line — a large feature, or a\nwhole separate build.\n\n**Interview.** A new project opens in an*Interviewing*phase: the agent asks you questions to capture the real intent and spec*before*touching anything.**Execute.** Once active, the agent drives the goal autonomously, spinning up tasklists inside the project's workspace.**Verify.** A**separate verification pass** checks the work against the captured goal and returns a gap list that feeds the next round of tasklists. A*quick*check judges the step summaries; a*full*check spawns an isolated, read-only inspector that opens files, reads diffs, and runs tests.**Finish — only when verified.** An agent can't mark its own project done: completion is**gated on a passing full verification**(generator and verifier are deliberately separate). If it can't get there within a bounded number of rounds, the project escalates to*Needs review*instead of quietly claiming success.\n\nThis verifier/generator separation is what makes handing over a big goal feel safe — and, because you can staff the workers with cheaper models, it doesn't have to be expensive.\n\nThe top rung: agents that work **without you initiating at all**. The Assignments page is one\nsurface across every agent, with a calendar view for scheduled runs and a list view for\neverything else. An assignment fires on one of three triggers:\n\n**Schedule**— a cron expression, plotted on the calendar (daily standups, nightly audits, a weekly digest).** Webhook**— runs when something POSTs to it (wire it into CI, a form, another service).** Connector event**— polls a connected data source (an[MCP](#extending-your-agents)connector) and fires when it changes.\n\nThe point is compounding: the very same agent you chat with to make changes can be *assigned*\nto review every incoming change against your preferences. It applies what it has learned from\nyou, and gets better at it over time — the reviewer and the author are the same evolving\nspecialist. Note that unattended runs [deny an unmatched permission prompt rather than assume\nconsent](#security--permissions).\n\nEverything above rides on one idea: **agents that get sharper the more you use them.**\n\n**Memory, in three scopes.** Agents keep durable notes scoped to themselves (**Agent**), to a repository (** Project**, keyed to the git repo), or to everything (** Global**), with sensible caps so memory stays curated rather than hoarded. Agents read and write memory as they work.** Nothing lands silently.**As a thread's working window fills (or it goes idle), a reflection pass reads just the new material and proposes candidate memories and skills. They're staged for you in**Settings → Memories**, where you accept, edit, or reject each one — and undo a write if you change your mind. A human is always in the loop before knowledge becomes durable.**Skills distilled from experience.** When an agent finds itself doing the same kind of procedure repeatedly, a distillation pass generalizes those repetitions into a reusable**Skill** template — always written*parked*(disabled) and pending your approval, never auto-enabled.**Kept tidy automatically.** Background passes consolidate near-duplicate distilled skills into the higher-use survivor and retire ones that have gone stale — scoped so they only ever touch machine-distilled skills, and always reversible.\n\nSome of this frontier is still evolving — outcome-signal-driven promotion and memory decay/eviction are active areas of work — but the observe → distill → human-review loop ships today.\n\nEverything an agent is and knows — profiles, threads, memories, skills, assignments — lives\nunder one data directory, `~/.launchpad_studio`\n\nby default. A **workspace** is a second one of\nthose, somewhere else on disk, with its own completely separate roster.\n\nThat is the unit to reach for when you want more than one org: a client's agents kept apart from your own, a throwaway set for experimenting without polluting memories you care about, work and personal on the same machine. Switching is not a filter over shared data — the two sets never see each other.\n\nThe workspace tile in the app manages this. You can **create** a workspace at any absolute path,\n**adopt** an existing Launchpad data directory by pointing at it, **duplicate** one to fork a\nwhole org, and rename or deregister them.\n\nFour behaviours are not obvious from the UI:\n\n**Switching restarts the app.** Activation only moves a pointer; persistence, the event bus and every in-memory store were wired to the root resolved at process start, so the change takes effect on relaunch and the app restarts itself to get there.**Deregistering never deletes your data.** Removing a workspace drops the registry entry and leaves every file on disk. Deleting the active workspace, or the last remaining one, is refused outright.**Setting** The environment variable pins the data root, and every workspace mutation is then rejected server-side rather than silently ignored. Pin the path or use the switcher — not both. This is deliberate, and it is the mechanism behind running two development tracks side by side.`LAUNCHPAD_STUDIO_DATA_DIR`\n\ndisables workspace switching entirely.**The registry lives at**, a fixed bootstrap path outside whichever root is active. It is a list of pointers, so it is tied to one machine and does not travel with a workspace you copy elsewhere.`~/.launchpad_studio/workspaces.json`\n\n**Collections** is one place to manage everything that extends what your agents can do, across\nthree tabs. **Skills** are reusable, model-invocable procedures (Markdown with a little\nfrontmatter), run either *forked* in a fresh subagent or *inline* in the current turn.\n**Plugins** are installable bundles of skills and rules, from a GitHub URL or a local path,\nwith install / uninstall / refresh and an optional auto-update toggle. **Connectors** are\n[Model Context Protocol](https://modelcontextprotocol.io/) servers (stdio or HTTP) that give\nagents new tools and data sources, each showing live connection status and its exposed tools,\nwith an in-app **Authorize** flow for auth-gated ones.\n\nA **Workflow** goes one level up: a reusable, versioned template that codifies a repeatable\nprocess as an ordered sequence of **phases**, where each phase is run by an AI agent\n(*Prompt*), a script (*Folder*), a user-filled form (*Input*), or a hard approval gate\n(*Pause*). Launch one from the Tasks sidebar — import your own, or use bundled and plugin ones\n— and each phase gets its own chat, form, or output viewer. Outputs flow forward from one phase\nto the next, agents can drive a workflow programmatically by pre-filling early phases from\nconversation context, and paused runs resume in one click.\n\n**Run modes.** Every agent runs in one of two, chosen when you create it and **not changeable\nafterwards**. **CLI mode** (default) drives an external agent CLI as a subprocess for each turn\nand normalizes its output — the batteries-included path, and the one that needs no API key.\n**Native / API mode** runs an in-process provider client directly, with no subprocess, against\nAnthropic, OpenAI, or OpenRouter. Both runners are constructed at startup and an agent's\n`runner_mode`\n\nalone decides which one its runs go to — there is no server flag to enable, and no\nfallback between them (`RunnerDispatcher::pick`\n\n). Both modes are driven by the exact same\ncomposed system prompt, so an agent behaves consistently regardless of how it's run.\n\n**Themes.** Eight named chrome themes — Midnight, Sapphire, Emerald, Plum, GitLab, Denim,\nGoodstuff FM, and iMessage — each with light and dark variants, plus an independent\nlight / dark / system toggle. The **custom theme generator** takes a pasted palette and maps it\nonto the app's color roles, deriving borders, secondary text, and dark-mode surfaces\nautomatically.\n\n| Document | What it covers |\n|---|---|\n|\n\n[CONTRIBUTING.md](/gigeey/launchpad-studio/blob/main/CONTRIBUTING.md)[KNOWN-GAPS.md](/gigeey/launchpad-studio/blob/main/KNOWN-GAPS.md)[guide/TELEGRAM.md](/gigeey/launchpad-studio/blob/main/guide/TELEGRAM.md)[guide/EMAIL.md](/gigeey/launchpad-studio/blob/main/guide/EMAIL.md)[SECURITY.md](/gigeey/launchpad-studio/blob/main/SECURITY.md)[CLA.md](/gigeey/launchpad-studio/blob/main/CLA.md)[THIRD-PARTY-NOTICES.md](/gigeey/launchpad-studio/blob/main/THIRD-PARTY-NOTICES.md)[dev/README.md](/gigeey/launchpad-studio/blob/main/dev/README.md)Outside this repository: ** gigeey.com**, and the\n\n[releases repository](https://github.com/gigeey/launchpad-studio-releases/releases)where the packaged macOS builds are published.\n\n**On platform support, precisely.** Launchpad Studio is developed and used on **macOS**, and\nmacOS is the platform it is packaged for. The Windows and Linux paths are not an afterthought —\ncredential storage is configured with a native backend for each of the three, and Tauri targets\nall three — but they are far less exercised, and **CI builds and tests the application on macOS\nonly**. The frontend test suite is also run on Linux against each supported Node version, but it\ntouches no platform-specific code, so a green tick there says nothing about a Linux build. Treat\na Windows or Linux build as something that ought to work rather than something that is verified,\nand please open an issue when it does not.\n\n**The version check can lock a source build out of the app.** If your checkout is far enough\nbehind the latest published release, the app replaces its entire UI with an update prompt that\noffers the official DMG and cannot be dismissed. \"Far enough\" is scored as `major × 1000 + minor`\n\nagainst `MAX_VERSION_DISTANCE`\n\n, which is 10, so eleven minor releases\nbehind will do it — and so will *any* major-version gap, because a single major bump scores 1000\non its own. Stated plainly: once `1.0.0`\n\nis published, a build from any `0.x`\n\ncheckout is blocked\nat launch. Build from a current checkout. The rationale, and the alternative that was considered\nand not taken, are written at the top of `frontend/src/utils/versionCheck.ts`\n\n. The gate does fail\nopen: if the request fails and nothing is cached the app starts normally, so being offline never\nlocks you out.\n\n**Two tests are flaky under a full parallel run**, and the tasklist co-pilot's enrolment\nplumbing is only partly ownership-aware. Both are written up with their diagnosis, blast radius,\nand the reason each was left, in ** KNOWN-GAPS.md**.\n\nLaunchpad Studio is a [Tauri 2](https://tauri.app/) desktop app: a React + TypeScript frontend\ninside a native shell, backed by a Rust workspace.\n\n— the UI (React + TypeScript).`frontend/`\n\n— the orchestration engine: agent runners, the tasklist / workflow / project schedulers, reflection, and skill distillation.`crates/ao-engine`\n\n— the HTTP server the frontend talks to.`crates/ao-server`\n\n— on-disk stores for profiles, threads, memories, and assignments.`crates/ao-persistence`\n\n— the shared type definitions.`crates/ao-protocol`\n\n— Model Context Protocol connector integration.`crates/ao-mcp-bridge`\n\n— SQLite FTS5 full-text search over memory, skills, and sessions.`crates/ao-search-index`\n\n— the agent tool implementations and provider clients.`crates/ao-engine-tools-*`\n\n— the handful of scripts contributors and CI actually run; see`dev/`\n\n, which also records what the packaging pipeline does and why it is not in this repository.[dev/README.md](/gigeey/launchpad-studio/blob/main/dev/README.md)\n\nA deeper build and development guide lives in ** guide/DEVELOPING.md**.\n\nContributions are welcome. Start with ** CONTRIBUTING.md** — it covers the\nbuild, the four test-suite traps that will otherwise cost you an afternoon, and the conventions\nthis codebase actually follows.\n\n**has the full development setup.**\n\n[guide/DEVELOPING.md](/gigeey/launchpad-studio/blob/main/guide/DEVELOPING.md)Two things worth knowing before you write code:\n\n**A** before a first pull request can be merged. The licence you grant is sublicensable, meaning contributions may be redistributed under other licences, including commercial ones. That is stated at the top of the document rather than buried in it, so you can decide before investing time.[Contributor License Agreement](/gigeey/launchpad-studio/blob/main/CLA.md)is required- Participation is covered by the\n.[Code of Conduct](/gigeey/launchpad-studio/blob/main/CODE_OF_CONDUCT.md)\n\n**Questions, bugs, and feature requests** go in\n[Issues](https://github.com/gigeey/launchpad-studio/issues) — the templates ask for the\nreproduction steps first, because for a bug they matter more than anything else in the report.\n**Security vulnerabilities do not**; see [SECURITY.md](/gigeey/launchpad-studio/blob/main/SECURITY.md).\n\nLicensed under the ** Apache License 2.0**.\n\nEvery dependency licence is inventoried in ** THIRD-PARTY-NOTICES.md**:\n775 Rust crates and 565 npm packages, transitive included, resolved for every target platform\nrather than for whichever one produced the file, with no unknowns. Nothing in either tree is\nunder the GPL, AGPL, SSPL, BUSL, or any source-available licence, and there are no git-sourced\nRust dependencies. The attribution obligations this project carries — five MPL-2.0 crates and\ntwo CDLA-Permissive data crates — are listed in\n\n**.**\n\n[NOTICE](/gigeey/launchpad-studio/blob/main/NOTICE)That inventory is generated, not maintained by hand:\n[ dev/generate-third-party-notices.mjs](/gigeey/launchpad-studio/blob/main/dev/generate-third-party-notices.mjs) rebuilds it from\nthe two lockfiles and fails if a dependency arrives under a licence this project does not ship.\n\nAs provided by section 6 of the licence, Apache-2.0 grants no rights to the \"Launchpad Studio\" or \"Gigeey\" names.", "url": "https://wpnews.pro/news/show-hn-an-open-source-workspace-for-your-agents", "canonical_source": "https://github.com/gigeey/launchpad-studio", "published_at": "2026-08-17 01:56:31+00:00", "updated_at": "2026-08-17 02:10:34.717023+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-products"], "entities": ["Gigeey", "Launchpad Studio", "GitHub", "Rust", "Node.js"], "alternates": {"html": "https://wpnews.pro/news/show-hn-an-open-source-workspace-for-your-agents", "markdown": "https://wpnews.pro/news/show-hn-an-open-source-workspace-for-your-agents.md", "text": "https://wpnews.pro/news/show-hn-an-open-source-workspace-for-your-agents.txt", "jsonld": "https://wpnews.pro/news/show-hn-an-open-source-workspace-for-your-agents.jsonld"}}