What happened
AvenoxBeyin’s guide, “Birden cok makinede kullanim,” describes a local-first setup for using the same vault on two computers, such as work and home machines. It says Beyin does not provide code synchronization or install Git; users synchronize the vault with a tool such as Git. Each machine installs and updates Beyin separately. Its SQLite runtime remains outside the vault, is machine-specific, and is reconstructed locally from Markdown files.
The guide distinguishes files that should be synchronized from files that should not. Notes and companion files, .beyin-daily-layout.json, .beyin-workspaces.json, the companion archive, receipts, and selected instruction files belong in Git. Generated views under daily/v3/ and knowledge/v3/ do not: they are produced from locally stored receipt data. The guide warns that syncing generated views can cause them to be treated as manually edited on another machine and stop updating. It provides suggested .gitignore and .gitattributes configurations, including exclusions for runtime pins, hooks, managed installation files, and local generated views.
For shared work on the same day, the guide recommends pulling before work and committing, rebasing, and pushing afterward. It says multiple sessions should not run Git commands simultaneously. With preferences --parallel-sessions on, an agent gets a one-line warning on its first prompt if another session in the same vault has been active in the previous 45 minutes. Session presence is represented by lightweight files in the vault and machine-local runtime markers; the guide says session-end hooks remove markers and entries older than 45 minutes are automatically removed.
The guide also covers conflict handling. Git conflict markers prevent sync from indexing the affected file until the conflict is resolved. File-sync services may leave conflict copies; Beyin warns about those rather than moving, deleting, or renaming them. For concurrent agent edits to human-written notes, it documents note-read and revision-checked note-edit commands instead of direct file writes, with hash-based conflict detection and instructions to reread and rebuild an edit after a conflict.
What the archive adds
New Runtime’s earlier coverage has described other ways to coordinate parallel agent sessions: Trace Canvas 0.3 maps parallel Claude Code and Codex sessions on one canvas and dispatches to-dos across machines (2026-10-31). This is a new product-specific guide to shared-vault synchronization and local runtime boundaries, rather than a restatement of that session-coordination story.
Trend signal
This supports agent security moves to runtime boundaries: the guide treats the local runtime and machine-specific installation state as boundaries that should not be casually copied between environments. The focus is operational consistency and safe file ownership, not a complete security model, so the connection is practical but limited.
Why it matters
Agent workflows increasingly span multiple sessions and devices, but synchronizing a workspace is not the same as synchronizing its execution state. Beyin’s distinction between shared Markdown and local SQLite state gives teams a useful design principle: make durable, reviewable inputs portable, while rebuilding machine-specific runtime data where it will be used.
The guide is also valuable for its treatment of failure rather than only the happy path. A cloud sync service may create duplicate files; Git may stop on conflicts; an agent edit may fail its hash check. The prescribed response is to surface those conditions and require human resolution, not silently pick a winner. That approach creates a clearer audit trail when multiple agents or operators touch the same working memory. Teams adapting this pattern can reduce accidental state replacement, but should map the guidance to their own tools and test restores before adopting a shared workspace as operational memory.
Limits and uncertainty
The guide documents the project’s intended behavior and recommended setup; it does not independently establish how reliably these safeguards perform across operating systems, Git configurations, or file-sync services. Its synchronization advice depends on users correctly identifying managed installation files and preserving per-machine backups. The 45-minute presence signal indicates recent activity, not that another session is still working or that two edits cannot conflict. The guide itself warns that some network filesystems may not provide the lock semantics its coordination relies on. It also cannot make a shared repository’s merge policy or human review process safe by itself.
Skill to build now
Before sharing an agent workspace across machines, inventory which files are source notes, generated views, receipts, and machine-specific installation state. Apply narrow ignore rules rather than excluding whole folders that may contain user scripts. Test the setup on a disposable clone: create a conflict, confirm it remains visible, and verify each machine can rebuild its local runtime from the synchronized sources.
Document an owner for repository operations during overlapping sessions. Have that person run pull, rebase, and push, while other agents continue only within their assigned files. Use content hashes or revision checks on writes, then rehearse recovery from a rejected edit and from a cloud-created conflict copy. The useful outcome is not merely shared access, but a repeatable procedure for deciding which state is authoritative.
Reader takeaway
Share the workspace’s durable inputs, not its machine-specific runtime. Keep generated views and installation state local, make conflicts visible, and verify recovery on each machine before trusting a synchronized vault as shared agent memory. Parallel access needs an explicit coordination and recovery practice, not just a sync folder.