Idea
Open-ended thinking issue, not a spec. Runway gives every Focus issue its own persistent terminal, but I have not actually settled what a terminal should be set up as when it spawns for real work. Right now a new Focus terminal is essentially a bare shell in a working directory, and I end up doing the same manual setup every time before the terminal is useful.
Filing this to collect the thinking before it turns into features, so the decisions are visible rather than accumulating as habits.
What I keep doing by hand
Worth capturing the actual repetition before designing anything:
- Picking the agent (Claude Code / Codex / plain shell) per terminal, every time
cd-ing to the right worktree rather than the repo root, since one issue means one worktree- Re-establishing context the agent needs: which issue, which branch, what the issue body says
- Re-running the same orientation commands (
git status, gh issue view, branch check) at the start of every session
- Splitting one issue across two terminals (agent + a shell for running things) and wiring both to the same directory
Open questions
- Per-issue defaults, or one global default? A
Cust:-scoped web issue and an Api: worker issue want different startup commands. Does the terminal setup key off the issue, the repo, the worktree, or nothing?
- How much should Runway pre-feed the agent? It already knows the issue number, title, body, and directory. Piping that in as an opening prompt is obvious and possibly annoying. Where is the line between helpful and presumptuous?
- One terminal per issue, or a small set? The accordion layout assumes one card per focus. An agent pane plus a run pane is the shape I actually use.
- Where does config live? A dotfile in the repo, a Runway-side setting per repo, or per issue? Repo-side means teammates inherit it; Runway-side keeps it personal.
- Does any of this belong in Runway at all, or is it a shell-profile problem that Runway should stay out of? Worth seriously considering the do-nothing option.
Acceptance
This issue is done when the questions above have answers written down, and any that turn into work are split into their own issues. No code needs to land from this one.
References
Sources/Runway/Terminal- README: "The terminal side", persistent GPU terminals, Quick terminal (
⌘⌥Q), issue-driven Focus board
Idea
Open-ended thinking issue, not a spec. Runway gives every Focus issue its own persistent terminal, but I have not actually settled what a terminal should be set up as when it spawns for real work. Right now a new Focus terminal is essentially a bare shell in a working directory, and I end up doing the same manual setup every time before the terminal is useful.
Filing this to collect the thinking before it turns into features, so the decisions are visible rather than accumulating as habits.
What I keep doing by hand
Worth capturing the actual repetition before designing anything:
cd-ing to the right worktree rather than the repo root, since one issue means one worktreegit status,gh issue view, branch check) at the start of every sessionOpen questions
Cust:-scoped web issue and anApi:worker issue want different startup commands. Does the terminal setup key off the issue, the repo, the worktree, or nothing?Acceptance
This issue is done when the questions above have answers written down, and any that turn into work are split into their own issues. No code needs to land from this one.
References
Sources/Runway/Terminal⌘⌥Q), issue-driven Focus board