It is 4 p.m. and three coding agents have been working on the same repository since lunch. One fixed rounding in the cart total, one added a discount code, one wrote tests. All three say "done". Before anything touches main, you want to know two things: did two of them rewrite the same function, and do the three changes still pass together?
Three screens for one codebase
osFoundry is a desktop app that puts chat, agents, files and tools in one window, and for code it gives you three related screens. Code is where you hand tasks to several agents at once: each run gets its own Git branch and its own working folder (a worktree), and you review, test and preview the merge before you decide anything. Nothing merges on its own. The IDE is a code editor for a local folder, with an explorer, source control, a terminal, problems and tests panels, and an assistant column that sees the file you are in. Wiki reads a repository on your machine and writes documentation pages that cite path:line, then marks a page when the code it cites changes. Code and Wiki sit as tabs next to Maestro, Model chat, Multi chat and Research; the IDE has its own item in the sidebar. If you know VS Code with a Git panel, the IDE will feel familiar. Code is closer to a pull-request inbox, except the authors are your agents and the branches never left your laptop.
A look at the Code tab
What you see on this screen (the runs are example data):
- The banner at the top of the rail. "3 agents finished · they disagree on 1 file" names the file, here
src/cart.js, before you open a single diff. The Review together button starts a joint review. - The run rail. Runs are grouped by what they need from you: Ready to review, Needs attention, and a folded History. Each row shows the task, lines added and removed, how long it worked, and its branch.
- The conversation in the middle. Click a run and you read what the agent was asked and what it said while working.
- The right panel. Changes, Files, Commits, Review and PR tabs show each run's real diff, uncommitted work first, then what it committed to its branch.
- The Merge station at the bottom right. Select finished runs and this is where you test them and preview merging them together.
Use case: a tech lead with three agents on one repo
Dana leads a small web team and splits a checkout sprint across three agent runs: fix rounding in cart totals, add a discount code to checkout, add tests for the price formatter. Each run started from New run with a one-line task and an agent picked for it, so each has its own branch and folder and none of them can trip over the others' files while working.
When the banner says they disagree, she ticks all three runs and clicks Review together. The Merge panel reads "3 runs · conflicts not checked yet · 3 not yet tested", which is an honest "we don't know yet" rather than a green light. Under it, src/cart.js is tagged contested, and the hunks from each branch are listed side by side: the rounding fix and the discount code both rewrote total().
Next she presses test on each run. The tests run inside that run's own worktree, so her own checkout is never touched. By default, "Tests must pass before a branch can merge", and that rule can be changed in Settings. All three pass, but passing alone is not the same as passing together, so she presses Preview combined merge. The app merges the branches in a throwaway copy first and reports back: two merge cleanly, one conflicts.
She merges the two clean branches into her current branch. Only at that moment does her branch change. The discount-code branch stays, so the agent can redo its change on top of the rounding fix. If she had wanted the best part of each attempt instead of whole branches, Combine into a branch lets her tick individual hunks and build a new branch from them.
One more detail that matters on long days: if the app stops while a run is working, the run comes back as Interrupted, not as "running", with the note that its branch is kept.
Use case: a solo developer refactoring with an assistant
Kenji maintains a shop front end on his own. This morning he needs to change formatPrice, and he is not sure who calls it. He opens the project folder in the IDE from the sidebar. The editor layout is the usual one: Explorer and Source Control on the left, tabs in the middle, Terminal, Output, Problems and Tests along the bottom, and the Assistant on the right, where he can start a synced chat or a local chat that stays on the device.
He right-clicks formatPrice and chooses Show Code Graph. The pane lists Callers and Calls. A filled dot means the call was read from the code itself; a hollow dot means it was inferred, so that one deserves a manual look. Impact of change follows callers of callers and, in this example, reads "15 symbols · 14 files · 3 tests". Clicking a row jumps to that line, and Send to chat hands the whole graph to the assistant as context.
Later the assistant edits a config file for him. In Source Control the file shows as modified, and when he opens it, a small robot mark and the status line say it was last written by AI, with the model and the reason it gave. Review opens a side-by-side diff against the copy saved right before that write, so he sees only that change. Here it shows a timeout cut from 30 seconds to 3, right under a comment saying large uploads take 20 seconds or more. He catches it before committing.
If an agent writes to a file while he still has unsaved edits in it, the editor says the file changed on disk while he was editing and offers Keep mine or Use the disk version, instead of silently picking one.
Use case: a support engineer who needs to understand the code, not change it
Priya works in customer support and is often asked how a part of the product behaves. She can read code but does not want to grep through a repository she does not own. In Wiki she uses Open a folder (or Clone a public repository with an https or git@ URL), and the app reads the project's structure on her machine.
Before writing anything into the project, Wiki asks. A dialog names the exact folder it will create inside the repo, and if she clicks Not now, nothing is written. Once she agrees, she uses Generate pages or Write a page for a single topic. Settings decide how much source each page is written from (Depth: Quick, Standard or Deep) and how many claims are checked (Verification: Off, Sample or Full, where Full roughly doubles the bill). The cost is shown before a page is generated.
Each page cites path:line, and clicking a citation opens that line in the IDE. A month later, a page in the rail is flagged because "a file this page cites has changed since it was written", which tells her to regenerate before trusting it. For a quick one-off question she uses the chat beside the pages, whose answers also cite path:line from that project, and where she can also ask for a new page in plain words, such as "write a page about the retry policy". The pages themselves are markdown files in the repository, so the team can review them in the same pull requests as the code.
Where Code, IDE and Wiki hand off
These three screens pass work to each other and to the rest of the app. A Wiki citation opens the IDE at the cited line, and the IDE has a Wiki for this folder button for the reverse trip. The IDE's Assistant and the chat beside Wiki pages are built on Maestro, the same assistant you use elsewhere in osFoundry, so asking there works the way it does in any Maestro chat. For searching a codebase by meaning rather than exact words, Indexes builds a local search index that Maestro can use. And when a Code run is ready to leave your laptop, Open PR opens a pull request for its branch.
The product pages show interactive demos of each: Code and the IDE.
Questions people ask first
Do I need the desktop app?
Yes. Code, the IDE and Wiki work on local folders, Git worktrees, a shell and language servers, so they run in the osFoundry desktop app.
Will an agent ever merge into my branch by itself?
No. Runs work on their own branches in their own folders. Your current branch changes only when you press merge, and by default only for branches whose tests passed.
Is Wiki a team wiki like Notion?
No. It writes documentation from a code repository, citing file and line, and flags pages when that code changes. It is for codebase docs such as an architecture overview or onboarding notes.
What happens to a branch that conflicts?
It stays where it is. You can merge the clean branches now and let the agent redo the conflicting one on top of them, or pick individual hunks with Combine into a branch.
The desktop app is free to download at osfoundry.io/download.
Top comments (0)