AccessTerm

KO | EN

gitlite — search

#framework #claude-code #automation #chatbot #go #linux #python #tailwindcss #large-language-models #deep-learning

(★ 9)

Accessible Terminal client for Mac.

파일 탐색기

ZIP 다운로드

- Info.plist
- - Announcer.swift
  - AppDelegate.swift
  - InputLineView.swift
  - main.swift
  - MainViewController.swift
  - Replay.swift
  - ShellIntegration.swift
  - TerminalPalette.swift
  - TerminalSession.swift
  - TerminalWindowController.swift
  - Transcript.swift
  - TranscriptStyle.swift
  - TranscriptTextView.swift
.gitignore
LICENSE
make-app.sh
Package.resolved
Package.swift
README.md
release.sh
run.sh

# CDN으로 사용하기

jsDelivr

jsDelivr는 공개 GitHub 리포지토리를 별도 설정 없이 CDN으로 즉시 서빙합니다. 버전과 파일을 고르면 웹페이지에 바로 붙일 수 있는 링크와 예시 코드가 만들어집니다.

버전

파일

링크

예시

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

AccessTerm is a macOS terminal built for VoiceOver users.

A normal terminal is one big text area that VoiceOver has to "interact with" before it can
read anything, and everything -- what you typed and what the computer printed -- lives in that
one area together. AccessTerm splits it up: output is a plain, read-only list of lines you can
arrow through, and there is a separate line at the bottom for typing. The output list is a
standard macOS control, so VoiceOver reads it the way it reads any list.

It needs macOS 13 (Ventura) or later.

**Contents**

- [Installing and running AccessTerm](#installing-and-running-accessterm)
- [What the window looks like](#what-the-window-looks-like)
- [Windows and tabs](#windows-and-tabs)
- [Keyboard shortcuts](#keyboard-shortcuts)
- [Programs that redraw the screen](#programs-that-redraw-the-screen)
- [Command blocks](#command-blocks)
- [What gets spoken](#what-gets-spoken)
- [Settings applied automatically](#settings-applied-automatically)
- [Diagnostics](#diagnostics)
- [Development notes](#development-notes)
- [Known limitations](#known-limitations)
- [Known issues](#known-issues)
- [Milestones](#milestones)
- [License](#license)

## Installing and running AccessTerm

The quickest way is the ready-made download: open the
[Releases page](https://github.com/allisonfm85/AccessTerm/releases), download the
`AccessTerm-<version>.zip` file under the newest release, unzip it, and move `AccessTerm.app`
into your Applications folder. It is signed and notarized with Apple, so it opens like any
other downloaded app.

If you would rather build it yourself, or want the very latest changes, you copy the source
code to your Mac and run one command that turns it into a working program. "Building" (or
"compiling") just means that translation step. You only have to do it once, and you do not
need to know anything about the code to do it.

The whole process is: install Apple's developer tools, download the code, run one command.
Expect ten minutes the first time, most of it spent waiting.

### Before you start: install Apple's developer tools

Building needs Swift, Apple's programming language, which comes with a free Apple download
called the Command Line Tools. If you already have Xcode installed, you already have this and
can skip ahead.

1. Open the Terminal app (press Command-Space, type `Terminal`, press Return).
2. Type this and press Return:

```
   xcode-select --install
   ```

3. If a dialog appears offering to install the tools, choose Install and wait for it to
   finish. It is a large download.
4. If instead you see a message saying the tools are already installed, you are ready.

That is all you need. AccessTerm builds with the Command Line Tools alone -- the full Xcode
app is not required. The build scripts below take care of the one setting that makes this
work, so there is nothing for you to configure.

### Step 1: get the code onto your Mac

If you know Git, clone the repository as usual:

```
git clone https://github.com/allisonfm85/AccessTerm.git
```

If you do not, go to <https://github.com/allisonfm85/AccessTerm>, use the green **Code**
button, choose **Download ZIP**, and unzip the file your browser saves. Either way you end up
with a folder named `AccessTerm`, wherever you chose to put it.

### Step 2: tell Terminal to work inside that folder

Terminal is always "in" one folder at a time, and it only sees the files there. The `cd`
command ("change directory") moves it, and it needs the path to wherever you put the
AccessTerm folder.

The way that works no matter where that is, without typing a path at all: type `cd ` (with a
space after it), then drag the AccessTerm folder from Finder onto the Terminal window, which
fills in its path for you, and press Return.

If you would rather type it, the command is `cd ` followed by that path. So for a copy
sitting directly in your home folder it is `cd ~/AccessTerm`, where `~` is shorthand for your
home folder.

Nothing visible happens when `cd` works. That is normal; silence means success. If you see
"No such file or directory", the path is wrong, not the app.

### Step 3: build and run it

There are two ways to do this. Both build the same program.

**The quick way -- try it now.** Type:

```
./run.sh
```

This compiles the app and launches it as soon as it is ready. The first run has to download
one component AccessTerm depends on (a terminal engine called SwiftTerm), so it needs an
internet connection that one time, and it can take several minutes. You will see a lot of
progress text scroll by; that is the build talking, not an error. Later runs are much faster.

While the app is running, the Terminal window you started it from stays busy. Quit AccessTerm
to get that window back, or press Control-C in it to stop the app.

**The tidy way -- make a real app you can double-click.** Type:

```
./make-app.sh
```

This does a slower, optimised build and then wraps the result into a proper macOS application
at `build/AccessTerm.app`. When it finishes it prints the path. Open it with:

```
open build/AccessTerm.app
```

From then on you can launch AccessTerm from Finder like any other app -- double-click it, or
drag it to your Applications folder first and launch it from there. You do not need Terminal
again unless you want to rebuild after updating the code.

### If you prefer Xcode

You do not need Xcode, but it works. In Xcode choose File > Open, select the `Package.swift`
file inside the AccessTerm folder, pick the AccessTerm scheme, and press Command-R to build and
run. Xcode downloads SwiftTerm on its own the first time.

Xcode builds with its own engine rather than the one the scripts select, so it compiles
SwiftTerm's Metal shader. If it stops with `unable to spawn process 'metal'`, install the
Metal Toolchain in Xcode > Settings > Components. The scripts above never hit this.

### If something goes wrong

| What you see | What it means | What to do |
| --- | --- | --- |
| `swift: command not found` | The developer tools are not installed | Run `xcode-select --install` (see above) |
| An error about `xcrun` or a missing developer directory | Same thing, or Xcode is not selected | Run `xcode-select --install`; if Xcode is installed, run `sudo xcode-select -s /Applications/Xcode.app` |
| `No such file or directory` after `cd` | Terminal is not in the AccessTerm folder | Check the path; drag the folder onto the Terminal window to fill it in |
| The build stops with a network or "failed to clone" error | It could not fetch SwiftTerm | Check your internet connection and run the command again |
| `unable to spawn process 'metal'` | The build tried to compile a shader AccessTerm does not use | Use `./run.sh` or `./make-app.sh` rather than `swift run` or `swift build`; they select the build system that skips it |
| `permission denied: ./run.sh` or `./make-app.sh` | The script is not marked runnable, which unzipping can cause | Run `chmod +x run.sh make-app.sh`, then try again |
| macOS says the app cannot be opened because it is from an unidentified developer | Gatekeeper does not recognise a locally built app | Control-click `AccessTerm.app` in Finder and choose Open, then confirm |

Remember to turn VoiceOver on (Command-F5) before you start using AccessTerm -- it is built
around VoiceOver, and a lot of what it does only shows up when VoiceOver is speaking.

## What the window looks like

Three areas, top to bottom. The Command shortcuts in the next section move between them from
anywhere in the window.

1. **Transcript** (a read-only text view, labeled "Transcript"). Everything that has been
   printed, one line per logical line. Long lines that wrapped on screen are joined back into
   a single line here. Because it is an ordinary text view, VoiceOver navigates it with the
   caret and reads by line, word, or character -- no interacting required. New lines are added
   at the end, and when a program repaints a line it already printed, that line is rewritten
   where it is instead of appearing twice (see [Programs that redraw the
   screen](#programs-that-redraw-the-screen)). Either way, your caret stays on the text it was
   on.
2. **Current line** (labeled "Current line"). The line the program has not finished printing
   yet: usually the shell prompt, a half-printed line, or a progress indicator. When the cursor
   is sitting on a blank row underneath something a program has just drawn, this shows the last
   line of that drawing rather than nothing.
3. **Command line** (labeled "Command line"). Where what you type appears. Press Return to
   send it. It is deliberately not a text field: a field is narrated by the system on its own
   terms, and emptying one on Return is described as a deletion -- which means the command
   read back at you a moment after you typed it. This is a plain view instead, so nothing is
   said that the app did not choose to say. What that costs is a caret: editing is typing and
   Backspace, and the shell does the rest (see below).

## Windows and tabs

File > New Window (Command-N) opens another terminal, with a shell of its own. File > New Tab
(Command-T) does the same but puts it in the same window as a tab, the standard macOS tab bar
that VoiceOver reads like any other -- and the system's usual tab commands (Show Next Tab,
Merge All Windows and so on) appear in the Window menu once there are tabs to use them on.
Command-W closes the front window or tab, and Option-Command-W closes them all -- each one
still asks first if a program is running in it.

Each terminal is separate: its own shell, its own transcript, its own command blocks. What is
shared is your ears, so only the window you are in speaks. A build running in a background tab
writes to its transcript in silence; you catch up by switching to it and reading, the same way
you review anything else. The one thing a background window says out loud is its bell --
a program asking for input is worth interrupting for -- and it names the window it rang in,
so "Attention in claude — AccessTerm" tells you which tab wants you.

Closing a window whose program is still running, or quitting while any window has one, asks
first: closing kills the program, and an editor or a Claude session should not die to a slip
of Command-W. A shell sitting at its prompt closes without a word.

## Keyboard shortcuts

These all use Command, so they never collide with VoiceOver's Control-Option commands. They
work from anywhere in the window.

| Key | Action |
| --- | --- |
| Command-N | New window |
| Command-T | New tab |
| Command-W | Close the front window or tab |
| Command-1 | Focus the transcript, caret at the last command you ran |
| Command-2 | Focus the command line |
| Command-Shift-E | Go to the end of the transcript |
| Command-Shift-L | Speak the current line |
| Command-Shift-S | Toggle speaking of new output on and off |
| Command-. | Send Control-C (interrupt whatever is running) |
| Command-Shift-C | Copy the entire transcript |
| Option-Command-Up | Previous command |
| Option-Command-Down | Next command |
| Command-Shift-O | Copy the output of the command the caret is in |

### While the caret is in the transcript

- **Up/Down arrow**: move one line; VoiceOver reads it. No interaction needed.
- **Left/Right arrow**: move one character. **Option-Left/Right**: move one word.
- **Shift** with any of those extends the selection. **Command-A** selects all.
- **Command-C** copies the selection; **Command-Shift-C** copies the whole transcript.
- **Command-F** opens Find (Edit > Find). Return and Shift-Return step through matches, and so
  do **Command-G** (Find Next) and **Command-Shift-G** (Find Previous) once the find bar has
  been dismissed. **Command-E** makes the selection the thing being searched for.
- **Command-1** puts the caret at the start of the last command you ran, which is also the top
  of that command's output. Before you have run anything, it goes to the end.
- **Option-Command-Up / Option-Command-Down** step between commands. Each stop lands on the
  command itself and speaks it, plus its exit code if it failed: "ls -la, exit code 1". If the
  caret is in the middle of a command's output, Option-Command-Up goes to the top of that
  command first, then on to the one before it.
- Inside a command that holds a conversation of its own -- a Claude Code session -- those same
  keys step between its turns instead, speaking each question. At the first turn, one more
  Option-Command-Up takes you to the command they all belong to ("claude"), and from there
  stepping continues through the shell's commands as usual. See [Turns inside a
  command](#turns-inside-a-command).
- **Command-Shift-O** copies the output of the command the caret is in, without the prompt or
  the command itself. Inside a turn, it copies just that turn's answer rather than everything
  the program has printed since it started.
- **Command-Shift-E** puts the caret on the last line, so VoiceOver reads it.
- New output only scrolls the view when the caret is already at the end. So moving back to
  re-read something holds your place, and Command-Shift-E puts you back to following along
  live.

### While the caret is in the command line

- **Return**: send the line. The text and the Return are sent as two separate writes. Programs
  work out whether input was typed or pasted by how much arrives at once, and Claude Code
  treats anything over about sixty bytes as a paste -- which used to mean a long line's Return
  was read as pasted text rather than "send this", and nothing happened. When the program has
  asked for bracketed paste, the text is wrapped in the paste markers too.
- **Up/Down**: the shell's own history. Anything typed and not yet sent goes to the shell
  first, so that its line and this one do not disagree; from then on you are editing the line
  the shell holds, which the Current line shows.
- **Tab**: shell completion, the same way -- what you have typed goes first, so there is
  something to complete.
- **Left/Right**: move the caret one character, and the character you moved over is read out.
  **Option-Left/Right**: one word, and the word is read out -- a word here is a run of
  anything that is not a space, so a path or a flag is one word. **Home/End**, or
  **Command-Left/Right**: the start and end of the line. At either end, it says which end you
  are at rather than going quiet.
- **Backspace** deletes the character before the caret and says what it was. **Forward
  Delete** takes the one after it. Typing anywhere in the line inserts at the caret.
- **Command-V**: paste. A single line is inserted for you to look at before it runs, rather
  than running on arrival. A paste with newlines in it is not flattened onto the line --
  newlines carry meaning, like a heredoc's terminator or the body of a loop -- so it is saved
  as a script and `source '<path>'` is put on the line instead. That is a command like any
  other: read it back, correct it, and press Return to run it, and the transcript records
  exactly what ran. While a full-screen program has the screen, a paste goes straight to the
  program instead, newlines and all, the way any terminal pastes.
- **Control-C, Control-D, Control-Z, Control-L, Escape**: sent straight to the program.
- **Shift-Tab**: sent to the program (Claude Code uses it to cycle permission modes).
- Typing itself is silent. Whether keystrokes are spoken is VoiceOver's own key echo setting,
  and the app does not answer that question on your behalf; the caret keys above are how you
  read back what you have typed before sending it.

The Terminal menu also has "Send Escape" and "Send Shift-Tab", for when a menu is easier than
a key combination.

## Programs that redraw the screen

A terminal is really a grid of character cells, and plenty of programs treat it as one: they
print something, move the cursor back up over it, and print it again with a word changed.
Claude Code's screen reader mode repaints its whole frame -- the message being streamed, the
spinner, the status lines, the input box -- several times a second, and patches single words
in place in between.

That means a line is not finished just because the cursor has moved past it. Every line in the
transcript remembers which screen rows it was built from, and when a program redraws one of
those rows, the line it produced is rewritten in place. A streamed reply reads as one line that
grows, rather than one copy per frame, and what the transcript holds at the end is what a
sighted user would have seen on screen.

Only two things reset that: the scrollback (the history the terminal keeps above the visible
screen) being discarded, and the screen being wiped with `clear` or Control-L. After either,
lines already in the transcript keep their text -- this is a transcript, not a screen -- and
rows start being tracked again from wherever the wipe left the cursor, so nothing already
written gets overwritten by what comes next.

New output is spoken only when it is genuinely new: a line is announced when its text is not
blank and is not what was last announced for that same line, so a frame that repaints the same
words says nothing.

## Command blocks

The transcript is divided into blocks. One block is a prompt, the command you typed, its
output, and how it ended. Blocks are what Option-Command-Up and Option-Command-Down move
between, what Command-Shift-O copies the output of, and what Command-1 lands on.

### Turns inside a command

A command that keeps running and holds a conversation with you should not be a single block
with a wall of output inside it. Claude Code marks the start of each turn, and prints your
question on a line of its own behind a `you:` label. Each of those becomes a block nested
inside the command: the question acts as its command line, the answer as its output, and it
ends where the next question starts.

So a Claude session is one `claude` block with one turn inside it per question.
Option-Command-Up and Option-Command-Down move between those turns while the caret is inside
the session, Command-1 lands on the most recent question, and Command-Shift-O copies that
turn's answer.

A program that does not mark its turns but does label them gets the same treatment from the
label alone: a line beginning with `you: ` starts a turn. Where real markers exist, they win,
so a question quoted inside an answer is not mistaken for a new turn.

### Where the block boundaries come from (the technical bit)

Boundaries come from OSC 133, a set of invisible escape sequences a shell prints to say
"a prompt starts here", "the command starts here", "it is running now", and "it finished with
this exit code".

You do not have to add anything to your dotfiles (the `.zshrc` and friends that configure your
shell). Zsh reads its startup files from whatever `$ZDOTDIR` points at, so AccessTerm writes a
directory of its own at `~/Library/Application Support/AccessTerm/zsh` and launches the shell
pointed at that. The files there source your own `.zshenv`, `.zprofile`, `.zshrc` and `.zlogin`
first, put `ZDOTDIR` back to yours afterwards, and then add the hooks that print the markers.
They are rewritten on every launch, so editing them has no lasting effect -- edit your own
dotfiles, which they run.

Claude Code's screen reader mode prints markers of its own, which is where the turns above come
from. It sends an `A` at the start of a turn and a bare `D` at the end of one; a shell's `D`
always carries an exit code, which is how the two are told apart. An `A` arriving while a
command is still running is also how the app knows it came from a program rather than a shell:
a shell is never prompting while its own command runs.

If no markers ever arrive -- a different shell, or a `$ZDOTDIR` you have locked down -- the
whole transcript is treated as one block. All the commands above still work; there is simply
one thing for them to work on.

## What gets spoken

- New output lines are batched every quarter second and spoken as one announcement. Bursts of
  more than 30 lines are summarised: "N lines of output. Last 30: ...".
- A line is only spoken when it says something new. Blank lines are skipped, and a line
  redrawn with the text it already had is not repeated. See [Programs that redraw the
  screen](#programs-that-redraw-the-screen).
- The command coming back is not spoken. A shell prints what you typed back at you, and that
  echo becomes a transcript line like any other -- but you typed it a moment ago, so hearing it
  read out says nothing you did not already know. The markers say where it is: everything
  between the end of the prompt and the command starting to run is your own typing. The markers
  only bracket what is typed at the shell's own prompt, so anywhere they do not reach -- a
  program running a prompt of its own, a shell too old to send them -- a line that is what was
  just sent, on its own or typed on the end of a prompt, is skipped once, which is how often
  the echo appears. It is only the announcement that is suppressed: the line is in the transcript,
  it is read when you arrow onto it, it is copied, and Command-1 still speaks it, because
  landing on the last command is something you asked for.
- Moving the caret in the transcript is read by VoiceOver itself, exactly as in any text area:
  the line, word or character you moved over, and VoiceOver's own wording for extending or
  shrinking a selection. The app adds nothing, so this follows your VoiceOver verbosity
  settings.
- When the app moves the caret for you (Command-1, Command-Shift-E), the line you land on is
  announced at high priority once focus has arrived. See [Known issues](#known-issues) for what
  VoiceOver says before it.
- A command that ends with a non-zero exit code -- meaning it failed -- has "exit code 127"
  (or whichever number) added to the end of the announcement of whatever it printed.
- A yes/no prompt is told what pressing Return alone will do. A line ending in `[Y/n]`,
  `[y/N]`, `[Y/n/a]` or `(default: yes)` is announced with "Press Return for yes." (or no) on
  the end. The capital letter is the default, so a prompt that names no default (`[y/n]`) gets
  no hint. Only the spoken announcement carries this; the transcript itself stays verbatim so
  copying it gives you exactly what was printed.
- A terminal bell speaks "Attention" plus the current line, at high priority. Claude Code's
  screen reader mode rings the bell when it wants input, so this is how you know it is your
  turn.
- Full-screen programs (vim, htop, an attached Claude session) switch the transcript to a
  screen view and speak rows as they change. This is still basic.

## Settings applied automatically

AccessTerm launches your shell with these environment variables already set, so the tools you
are likely to use behave well with a screen reader without you configuring anything:

- `CLAUDE_AX_SCREEN_READER=1` — turns on Claude Code's screen reader mode (v2.1.181 or later).
- `GH_ACCESSIBLE_PROMPTER=1`, `GH_ACCESSIBLE_COLORS=1`, `GH_SPINNER_DISABLED=1` — the same for
  the GitHub CLI.
- `TERM_PROGRAM=AccessTerm` so other tools can tell they are running here.
- `ZDOTDIR` points at the app's own zsh startup files, which source yours. See [Command
  blocks](#command-blocks). Your original value is kept in `ACCESSTERM_USER_ZDOTDIR` and
  restored before your `.zshrc` finishes, so anything you launch sees the value you set.

## Diagnostics

This section is for tracking down bugs in AccessTerm itself. You can skip it unless you are
reporting a problem or want to see why a program came out looking wrong.

Setting `ACCESSTERM_LOG` to a file path makes the app append every byte it reads from the
terminal to that file, exactly as it arrived, escape sequences and all. Nothing else changes.
It exists so you can compare what a program actually sent against what the transcript made of
it.

Environment variables like this have to be set for the app's own process, which means putting
them in front of the command that starts it, and starting the program inside the app bundle
directly rather than using `open`:

```
ACCESSTERM_LOG=/tmp/raw.log ./build/AccessTerm.app/Contents/MacOS/AccessTerm
```

The raw log records what a program printed, but not what it was answered with.
`ACCESSTERM_HEXLOG` adds that: every byte written to the terminal as a `TX` line and every byte
read as an `RX` line, in hexadecimal with a millisecond timestamp. This is what a prompt that
looks stuck needs, because it shows whether an answer was sent at all and what the program did
next:

```
ACCESSTERM_LOG=/tmp/raw.log ACCESSTERM_HEXLOG=/tmp/raw.hex \
    ./build/AccessTerm.app/Contents/MacOS/AccessTerm
```

(The backslash at the end of the first line just means "this command continues on the next
line"; you can type it all on one line instead.)

If you set only `ACCESSTERM_LOG`, the hex log is written to that same path with `.hex`
appended. Both logs are off unless their variable is set.

A capture can be replayed through the transcript machinery with no window, shell or terminal
involved, which turns a program that came out wrong into a repeatable test:

```
./build/AccessTerm.app/Contents/MacOS/AccessTerm --replay /tmp/raw.log
```

It prints the transcript the capture produces after a `--- transcript ---` marker, and the
current line on standard error.

## Development notes

Notes for anyone working on AccessTerm itself, kept here because each one cost a day to find.

- A menu item's key equivalent is not reliably yours. Key equivalents are offered to the key
  window before they reach the main menu, so any chord a system view wants, it takes:
  Option-Command-W reached the tab machinery, which closed a single tab, while File > Close
  All -- the same action, clicked -- closed everything. A chord that has to work has to be
  read off the keyboard with a local event monitor and the event swallowed there. This has
  bitten twice: block-stepping first, then Close All.
- Cutting a release is one command: `./release.sh 0.2.0` sets the version, builds a universal
  app, signs and notarizes it, tags the commit, and publishes the GitHub release with the zip
  attached. Notarization needs a one-time `notarytool store-credentials` setup, described at
  the top of the script; without it the script still works but warns and skips that step.

## Known limitations

- The terminal is a fixed 160 columns by 50 rows and does not follow the window size.
- Accented characters typed with dead keys, and input methods that compose as you type, are not
  supported at the command line: keys are read directly rather than through an input context.
- After 100,000 lines, the transcript stops growing. Restart the app for now.

## Known issues

**VoiceOver reads the first line of the transcript when it takes focus.** Command-1 and
Command-Shift-E move the caret to the line you asked for and announce it, but VoiceOver reads
the first line of the transcript first, whatever the caret is doing. You hear the wrong line,
then the right one.

Things that were tried, none of which stopped it:

- Overriding the accessibility attributes the text could be read from -- value, visible
  character range, number of characters, and string and attributed-string for a range --
  either narrowed to the caret's line or blanked entirely.
- Reporting the view as static text instead of a text area, so VoiceOver would read it through
  the visible range rather than as an entry area.
- A quiet window: reporting nothing readable at all for a third of a second around the focus
  change, then restoring and posting selected-text-changed rather than value-changed.
- Swapping the contents themselves, so the text view held only the landing line while focus
  arrived, and putting them back half a second later.

The read appears to come from a path that consults none of those. This is parked: the
high-priority announcement of the landing line is the workaround, and everything else is back
to being an ordinary text area, which is what VoiceOver navigates best.

The read that comes with the *selection* changing is a different one, and that one is dealt
with. Landing the caret used to post selected-text-changed, which asks VoiceOver to read the
landing line, and then talk over it with the announcement a tenth of a second later -- you
heard a syllable of the line and then the command. The notification is no longer posted when
there is something to announce, and the view reports nothing readable until the announcement
goes out, so the announcement is the only voice. Unlike the focus read, this path does consult
the attributes the view reports.

## Milestones

1. **Done** — PTY, headless VT engine, accessible transcript, command field, announcements.
2. **Done (where the project is now)** — shell integration via OSC 133: command and output
   blocks, jumping between commands, copying output on its own. Custom VoiceOver rotors for
   commands, errors and Claude turns are not in yet.
3. **Planned** — better support for full-screen programs, and a direct-input mode.

## License

MIT. See [LICENSE](LICENSE).

AccessTerm

오너의 다른 레포

파일 탐색기

# CDN으로 사용하기

Was this content helpful?

Recent Feedback

AccessTerm

오너의 다른 레포

파일 탐색기

# CDN으로 사용하기

Was this content helpful?

Recent Feedback

Download README