---
type: "post"
id: "version-3-5-1-adds-support-for-parallel-6e35f3"
slug: "version-3-5-1-adds-support-for-parallel-6e35f3"
title: "Version 3.5.1 adds support for parallel sessions and multiple machines that share the same vault."
description: "AvenoxBeyin’s multi-machine guide explains how to use one synchronized vault across computers without synchronizing machine-specific runtime state or installation files."
retrieval_nugget: "AvenoxBeyin’s multi-machine guide explains how to use one synchronized vault across computers without synchronizing machine-specific runtime state or installation files. For builders using agent-assisted notes across devices, its value is a concrete boundary: sync the Markdown source of truth, while each machine rebuilds its own local runtime."
published_at: "2026-11-14"
updated_at: "2026-11-14"
record_date: "2026-11-14"
date_kind: "published_at"
topics: ["claude","claude-code","codex"]
entities: ["AvenoxBeyin","AvenoxAI","Git","Claude Code","Codex"]
related_patterns: ["agent-security-moves-to-runtime-boundaries"]
novelty_label: "new_fact"
what_changed: "AvenoxBeyin v3.5.1 documents support for parallel sessions across multiple machines sharing one vault."
prior_refs: ["https://newruntime.com/posts/trace-canvas-0-3-maps-parallel-claude-code-426c72/"]
source_url: "https://github.com/avenoxai/avenoxbeyin/blob/main/docs/v3/MULTI-MACHINE.md"
source_urls: ["https://github.com/avenoxai/avenoxbeyin/blob/main/docs/v3/MULTI-MACHINE.md"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:version-3-5-1-adds-support-for-parallel-6e35f3"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/version-3-5-1-adds-support-for-parallel-6e35f3/","markdown":"https://newruntime.com/posts/version-3-5-1-adds-support-for-parallel-6e35f3.md","json":"https://newruntime.com/posts/version-3-5-1-adds-support-for-parallel-6e35f3.json"}
markdown_url: "https://newruntime.com/posts/version-3-5-1-adds-support-for-parallel-6e35f3.md"
---

# Version 3.5.1 adds support for parallel sessions and multiple machines that share the same vault.

## Retrieval answer

AvenoxBeyin’s multi-machine guide explains how to use one synchronized vault across computers without synchronizing machine-specific runtime state or installation files. For builders using agent-assisted notes across devices, its value is a concrete boundary: sync the Markdown source of truth, while each machine rebuilds its own local runtime.

## Summary
AvenoxBeyin’s multi-machine guide explains how to use one synchronized vault across computers without synchronizing machine-specific runtime state or installation files. For builders using agent-assisted notes across devices, its value is a concrete boundary: sync the Markdown source of truth, while each machine rebuilds its own local runtime.

## 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](https://newruntime.com/posts/trace-canvas-0-3-maps-parallel-claude-code-426c72/) (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](https://newruntime.com/patterns/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.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Claude](https://newruntime.com/topics/claude.md): Explore the claude topic hub.
- topic hub: [Claude Code](https://newruntime.com/topics/claude-code.md): Explore the claude-code topic hub.
- topic hub: [Codex](https://newruntime.com/topics/codex.md): Explore the codex topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)