VIEWPORT
For developers

Daily driver loop

What an average day looks like once Viewport is set up. The real rhythm, not a hello-world demo.

This page is for once you're past quickstart. You have one or two repos bound. The daemon is paired. Your phone gets pushes. What does an average day actually look like?

The morning

# coffee, open laptop
vpd status            # confirms daemon is up, relay connected
cd ~/code/api
git pull
claude                # or whatever agent you use

You give the agent a task. Usually a paragraph of intent. The agent starts.

In the Viewport web app, /sessions shows the new row, active, with a live "thinking" indicator. You can keep the tab open and watch frames flow in. Or you can close it.

The middle of the morning

You're doing something else. A meeting, lunch, another repo. The agent hits its first decision point. Phone buzzes.

You glance:

Claude Code paused
~/code/api · plan review
Refactor auth middleware (12 steps, 9 files)

You tap. Read the plan in ~30 seconds. The plan structure:

  • Goal. One paragraph the agent thinks it's solving.
  • Approach. 3-6 numbered steps the agent intends.
  • Files. The set of files it expects to touch.
  • Risks. Anything the agent flagged as potentially destructive.
  • Tests. What it plans to run after.

If it looks right: Approve. The agent moves on.

If something's off: Reply with a comment ("don't touch auth-cookie.ts, that's still in flight"). The agent reads the comment and re-plans. New plan comes back. You tap Approve revision.

The middle of the day

Permission gates. The agent wants to do something the workflow flagged as risky. Examples:

  • Delete a path matching **/node_modules/**.
  • Run a migration that drops a column.
  • Push a branch to remote.

These show up faster than plan reviews. Usually a one-line question:

Allow rm -rf node_modules in ~/code/api? Allow once / Allow always / Deny

You hit Allow once and the agent continues. The decision writes to the audit log with your name, timestamp, and the exact path.

The afternoon

The agent proposes new memory. It's been working in the repo for a few hours and noticed something useful. A convention, a runbook, a "watch out for X." It surfaces a context candidate:

I learned: the auth middleware uses a deprecated cookie format that gets rewritten by legacy-auth-bridge.ts:42 before reaching the new handlers. Worth saving for future sessions in this repo.

You read the preview. Three reactions are common:

  • Approve. It goes into the org's vault, encrypted client-side, never plaintext on the server.
  • Edit and approve. Adjust the wording.
  • Discard. Not worth saving.

See Context Vault for the encryption story.

End of session

The agent reports completion. Phone:

Claude Code completed
~/code/api · session ses_…
12 files changed · 1 PR opened

You open the PR link, review the diff like you'd review a human PR, merge or comment.

Across multiple repos

If you've got the daemon watching ~/work/ recursively, you might run agents in three repos at once:

# terminal 1
cd ~/work/api && claude

# terminal 2
cd ~/work/web && claude

# terminal 3
cd ~/work/sdk && codex

The inbox lists items from all three. You decide in whatever order they arrive. Each session is pinned to its repo's resolved workflow, so risky-path rules and approval routing apply correctly per-repo.

Across multiple orgs

If you belong to multiple orgs (work, personal, OSS), each org has its own:

  • Workspaces and members.
  • Workflows and approval policies.
  • Inbox and audit log.
  • Push notifications.

Switching orgs in the web app is a fullscreen transition. Your tenant context flushes and the new org loads cleanly. See Concepts: Organizations and teams.

On your phone, pushes from all orgs land in the same notification thread, tagged with the org name.

Common decisions about the loop

After a few weeks, you'll usually want to tune:

  • Plan-review threshold. If most plans are obvious, auto-approve plans with under N file changes. See Approval policies.
  • Permission-gate scope. Decide which risky paths actually need review vs. which can auto-pass. Configurable per workflow.
  • Notification channels. Mute web push during meetings, route to Slack only. Settings page.
  • TTLs. Default 1 hour might be too long if you want fast loops or too short if you take meetings. Per-workflow override.

Where to go next

On this page