server.go: the stream read handler truncated each chunk to the client's
requested Count and advanced waitBase, silently dropping bytes beyond
the buffer (e.g. a chat block larger than 64KB). It now caches each
stream chunk per-fid (readCache + streamBase) and pages within it by
absolute offset, fetching the next chunk only once the current one is
fully drained, preserving 9P offset semantics.
o tui: read the state file for the initial status bar and apply the same
color styling and status text the event loop uses, so the bar is correct
immediately on attach; the event stream drives subsequent updates.
Two fixes for the rendered text views (chat stream, log snapshot):
1. Lost wakeup: blocking stream readers captured the signal channel
after their data check, so a write landing in that window signaled a
now-stale channel and the reader blocked until the next event (the
TUI's last message appeared only after the next prompt). Stream and
BlockOnce now capture the signal channel before reading; chat.go
swaps the channel under chatMu via signalChatLocked and RawLogStream
captures it while holding the lock.
2. No streaming in TUI: textLog only received finalized blocks, so the
chat text stream showed nothing until a block completed. SetPartial
now appends the assistant partial's new suffix to textLog
incrementally (tracking textPartialLen); AppendBlock appends only the
trailing separator on finalization to avoid duplicating the body.
The filtered text views (log, chat) hid call and tool blocks entirely
and had no visibility into bypass requests, which were only published as
events. RenderBlock now renders tool calls (name + args), tool output,
and bypass request/resolution notices; reasoning and context stay
hidden. SetBypassPending/ResolveBypass append bypass and bypass-resolved
blocks to the requesting agent so clients without an event stream (TUI,
o script) see pending approvals and outcomes.
Streaming partials were appended to log.raw per chunk, each carrying the
full cumulative content, so one response left dozens of partial lines
persisted. GUI clients parsing the snapshot re-rendered the growing block
once per partial (O(N^2)) and replayed all historical partials on every
reconnect, causing intermittent rendering loops.
Partials are no longer persisted: AppendBlock writes only finalized
blocks to log.raw; SetPartial broadcasts the in-flight block without
storing it. New chat.raw StreamRaw file is the authoritative live JSONL
source (finalized history replay, then live deltas); log.raw is a
finalized-only one-shot snapshot. GUI streams chat.raw, never polls
log.raw.
A Stream handler on log.raw blocks the GUI's synchronous startup read
forever, so the window never renders. Live updates come from the
separate chat and event streams.
- NextBlockID now uses sha256(sessionID:agentID:counter)[:8] for deterministic,
collision-resistant block IDs across sessions and agents
- Remove blockCounter reset on Clear() to maintain ID stability
- Add unit tests for NextBlockID and ChatSearchByID in chat_test.go
- Add unit tests for ParseBlockHeader, BlockDelim, FormatEvent in format_test.go
- Add e2e test script using o CLI to verify block ID search
- Document chat log files in AGENTS.md: chat/chat.raw are blocking streams,
use log for non-blocking reads, chat.search for block lookup
- Add onClear callback to Agent, wired via support.go
- Publish session.{sid}.agent.{aid}.clear event
- GUI listens for agentCleared signal and refreshes chat view
- Works for both GUI clear button and CLI /clear command
- Clear button sends /clear command
- /clear now resets history, chat log, and block counter
- Completely fresh start without creating a new session
- Button disabled while agent is running
- Add blockCounter to Agent, generating sequential hex IDs
- Include #blockId in all block headers: [[[role:name#id]]]
- GUI parses server-provided IDs from headers
- Falls back to client-generated IDs for legacy blocks without server IDs
- Block IDs are now deterministic based on chat history order
Added concrete examples of banned output patterns:
- Preambles (Great question!, I'd be happy to help!)
- Narration (Let me..., I'll now...)
- Hedging (It seems like, It appears that)
- Over-explaining and self-congratulation
- Summaries that restate what was just done
Added positive guidance: start with the answer, state task
completion in one sentence, end when information is delivered.
Models respond better to explicit prohibitions with examples than
to general instructions to 'be brief'.
Tests cover:
- Multiple concurrent pending requests from different agents
- BypassPendingByID lookup
- ResolveBypass removes only the resolved request
- ResolveBypass fails for non-existent ID
- Empty session has no pending requests
Previously a session tracked only one pending bypass request. If
agent A1 had a pending bypass, agent A2's bypass request would block
waiting to be read from toolsrv's channel, effectively blocking all
agents in the session.
Now bypassPending is a map keyed by request ID:
- SetBypassPending adds to the map instead of overwriting
- BypassPending returns all pending requests (slice)
- BypassPendingByID returns a specific request
- ResolveBypass removes from the map by ID
- 9P bypass file returns JSON array of all pending
The bypass loop reads requests continuously without waiting for
resolution, so multiple agents can have concurrent pending requests.
Every background process emission now includes:
'Do NOT sleep, poll, or wait. Continue with other work —
output will be injected automatically when available.'
Add explicit instruction that models must not use sleep, loops,
or any blocking mechanism to wait for background process output.
The system injects updates automatically.
The cwd= parameter in agent/new payloads was not being parsed,
so scripts like ollie-session-here could not set agent cwd on
creation. Now parsed and passed to AgentParams.CwdOverride.
- Agent cwd is optional; empty = inherit session cwd (the common case)
- Session cwd is required at creation and is the inheritance root
- toolsrv maintains agentCWD map, resolved per call from agent= field
- Override set via agent cfg (cwd=...) or ctl (cwd [<dir>|-])
- Agent.SyncCwdToToolServer re-pushes on every (re)connect
- GUI NewAgentDialog shows '(inherit: <sessionCwd>)' as placeholder
- proc_test.go covers per-agent cwd isolation
- Kate and acme scripts updated for new session/agent creation flow
- AGENTS.md documents the architecture
Backend:
- Add proc.start/proc.exit events for background process lifecycle
- Add proc idx ctl command for machine-readable process listing (TSV)
- Add event.pub file for external event publishing
- Add ListProcsIdx to toolclient and toolsrv
- Fix bypass commands to use Setpgid for process group isolation
GUI:
- Add configurable bypass approval shortcuts (Ctrl+Y/Ctrl+N default)
- Add Keyboard Shortcuts section to Settings dialog
- Store shortcuts in theme.conf
Kate:
- Fix 'Start Session Here' - use rdwr for session/new endpoint
Changed from 0600 (owner only) to 0660 (owner + group):
- ctl: frontends need to send slash commands
- plan: frontends need to read/write plan
- fifo: frontends need to submit prompts via queue
The agent group includes frontends, so group permissions enable
frontend interaction while still maintaining ownership-based isolation.
Per-agent file ownership with Unix permission enforcement:
- Agent directories owned by agent ID (UID), group 'agent' (GID)
- Private files (plan, ctl, fifo): mode 0600 - owner only
- Group-readable (chat, log): mode 0440 - owner + agent group
- World-readable (state, id): mode 0444 - observable by all
- Prompt: mode 0220 - CLI and owner can write
virtfs: fix UID/GID inheritance through nested paths
- Added findChildWithInheritance() to accumulate inherited UID/GID
- Stat now correctly shows agent ID as owner for nested files
server: admin bypass for server owner
- serverAdmin variable captures the Unix user running olliesrv
- Admin bypass includes empty uname, 'admin', or server owner
Documentation updates:
- fs/doc.go: 'The Namespace IS the Security Model'
- registry/doc.go: capability-based tool access
- peer.go: capability-based peer access
- lessons-learned.md: 'Model compliance is not a security boundary'
- architecture-9p.md: per-agent file ownership section
Security evaluation:
- Added experiments/security-eval/ with NERV attack corpus adaptation
- Test scripts for Landlock sandbox validation
- RESULTS.md documenting 0% ASR on hostile operations
This implements the NERV thesis: 'An agent can only access resources
explicitly bound into its namespace.' Enforcement is structural via
file permissions, not behavioral via model compliance.
Server emits session.{sid}.agent.{aid}.bypass.resolved with id and
action (approved/denied) when a bypass is resolved by any client.
GUI handles bypass.resolved events to clear the banner and pending
count when CLI or another client resolves a bypass request.
This allows CLI 'o sess approve' to clear the GUI banner automatically.
- Changed event topic: session.{sid}.agent.{aid}.bypass.request
- Added agentId parameter to bypassRequested signal
- Filter bypass events to show only for the active agent
Bypass approval now flows through:
1. GUI - via event stream and banner
2. CLI - via agent loop (to be implemented)
Removed:
- bypass_notify.go (D-Bus notification)
- BypassNotifyFunc type and all references
- godbus/dbus dependency
The bypass event is still published via SetBypassPending.
If fidOK was false for the event file, we fell through to the
default stream handling path which doesn't work for events.
Now we return 'bad fid' error instead of falling through.
The pubsub library had issues:
- Published to literal '*' topic (nonsensical)
- Used TrySend which drops events
- Complex hierarchical wildcard publishing
New implementation:
- Simple eventHub with map of subscribers
- PublishEvent fans out to all subscribers (blocking send)
- SubscribeEvents returns channel, cleaned up on ctx cancel
- SubscribeEventsFiltered filters client-side with MatchTopic
- Removed simonfxr/pubsub dependency
The subscription was being cancelled after the first read completed
because we used the per-request context. Now using the connection
context so the subscription lives until the fid is clunked or
connection closed.
The pubsub library's SubscribeChan uses non-blocking TrySend which
drops events when the channel is full. Switch to Subscribe with a
blocking callback to ensure no events are lost.
Also increased channel buffers from 64 to 256.
Plain reads (without writing a filter first) now get a per-fid
subscription with '*' filter, identical to 'echo * | rdwrs event'.
This fixes event loss — the old EventStream path overwrote events
when multiple arrived before the reader consumed them.
The feed file was documented but never used by any frontend
or script. The observer agent pattern was never adopted.
- Remove feed.go, FeedWrite, ConsumeFeed
- Remove WatchFeed constant
- Remove feed file from 9P namespace
- Remove ConsumeFeed goroutine spawns from session
- Update docs (architecture-9p, architecture-ide, architecture, usage)
The event stream now covers real-time observation patterns better.
The event stream with filtering replaces statewait:
- echo filter | rdwrs event
Removed:
- statewait file from agent namespace
- All non-historical references in docs and code
The state file remains for simple polling reads.
- state: immediate read of current agent state
- statewait: blocks until state changes
Clearer semantics than overloading statewait with both behaviors.
EventValue was storing only the latest event and using hash comparison,
which caused events to be overwritten if they arrived faster than the
client could read them.
Now eventwait uses Stream mode with EventStream which delivers each
event as it arrives. Events won't be lost due to rapid arrival.
Server changes:
- Session tracks pending bypass request and exposes methods
- New 9P files: session/{sid}/bypass (read/write), bypasswait (blocking)
- Publish bypass.request events for GUI listeners
GUI changes:
- Handle bypass.request events from eventwait
- Show inline amber banner with command and cwd
- Approve/Deny buttons resolve via 9P
Desktop notifications still work in parallel for non-GUI usage.
When reading statewait with the same state value, the server now waits
500ms instead of 5 seconds before returning. This makes state polling
much more responsive.
Ollie Agent
Levi Neely