This guide covers coding agent notifications in Otty 1.6.2 on macOS. It focuses on Claude Code, Codex, and OpenCode sessions running in Otty terminal panes. The Windows beta has its own interface and release scope; the macOS settings and shortcuts here should not be treated as Windows instructions.
An agent can spend several minutes working, then stop at a question while you are reading a diff in another tab. A completion notification tells you a turn ended. An awaiting-input notification tells you the session needs a decision. Keeping those signals distinct makes it easier to decide which tab deserves your attention next.
What does an agent notification actually tell you?
Otty's agent integration reports lifecycle state from a supported coding agent to the terminal. That state can drive a tab badge, a system notification, or the organization of your Inbox. It gives you a way to find work that needs attention without continually visiting every session.
A completion event means the agent finished its current turn. It does not prove that the requested change is correct, that tests passed, or that the entire project is finished. An awaiting-input event means the agent needs a response, which could be an approval or a question about the task. You still read and answer that request in the agent session.
| Signal | What to do with it | What still needs checking |
|---|---|---|
| Processing badge | Let that session keep working while you handle another task | Whether it is progressing toward the right goal |
| Task completed | Return when you are ready to review its response | Diffs, test results, and any remaining work |
| Awaiting input | Open the session and read the request | What you are approving or answering |
| Shell command failed | Inspect the command and its exit status | Whether it belongs to the agent's current task |
The last row is a different signal. A compiler process can fail while an agent continues investigating the error. Conversely, an agent can finish a turn with a useful explanation without ever launching a compiler. Treat the two as separate observations.
How do you enable Claude Code, Codex, or OpenCode notifications?
Install and authenticate the agent CLI you want to use, then open Otty Settings with ⌘,. In Otty 1.6.2, Agents contains the integration controls. Turn on the integration for your agent and confirm that the row reports it is installed. You keep launching the same CLI in a terminal pane.
The integration needs the agent to load its updated configuration. Restart an agent that was already running when you installed the integration. For OpenCode, send a message after restarting so the plugin reports its session. For Codex, complete the trust prompt if it appears after restarting or updating.
The default installation locations are:
| Agent | Default integration location |
|---|---|
| Claude Code | ~/.claude/settings.json |
| Codex | ~/.codex/hooks.json |
| OpenCode | ~/.config/opencode/plugins/ |
These paths describe where the integration is installed, rather than files you need to rewrite by hand. Otty adds its own integration entries. The agent setup documentation explains the installation controls and how to remove the integration later.
If you keep an agent's configuration outside its normal folder, expand that agent's integration settings and check Config home. This option is available in 1.6.2. Installing into a default folder that your actual CLI never reads will leave the terminal without the expected lifecycle events. After changing the home, restart the CLI that will use it.
Which notification settings should you turn on?
Enable Notify When Task Completes and Notify When Awaiting Input for the sessions you want to monitor. The corresponding badge options provide a persistent visual cue when a banner has already disappeared. Agent behavior settings provide defaults, and the tab's Notifications & Privileges controls let you adjust an individual session.
For a background implementation task, both notification types are useful: one brings you back for a decision, the other brings you back for review. For a session you are actively watching, a completion banner may add little value. Choose the behavior according to how you use that tab rather than enabling every possible sound and badge everywhere.
Agent events and shell command events have separate controls. Notify on Finish, Notify on Error, and Notify on Watch Finish relate to commands in the shell. Turning on shell command completion alone is not the same as enabling an agent's awaiting-input notification. Start with the agent controls when your question is whether Claude Code, Codex, or OpenCode needs you.
The notification reference covers the shell and program-generated notification paths. You do not need to write a custom escape sequence or a polling script to use the installed coding agent integration.
Why can a badge appear without a macOS banner?
A badge and a banner use different presentation paths. Otty can know that a session is waiting while macOS prevents a banner from appearing. First check System Settings → Notifications → Otty, allow notifications, and select a banner style you can see. Also check whether Focus is suppressing the notification.
Next, test while another application is frontmost. Otty has a Notify While Foreground policy under Settings → Shell → Notification that affects notifications while you are using Otty. Choose Only when source tab is unfocused to hear from other tabs, or Always for foreground notifications regardless of the source tab. The first option distinguishes tabs, so another split within the current tab does not count as an unfocused tab. A quiet foreground test does not by itself demonstrate that the agent integration failed.
A missing sound is another separate question. A visible notification can be silent. Otty exposes notification sound options for shell notifications, and macOS has its own per-application notification controls. Verify that a banner arrives before using sound as your only success criterion. If you prefer quiet work, tab badges and Inbox remain useful without audible alerts.
How does Inbox help with several running agents?
Otty 1.6.2 includes Inbox, introduced in 1.6.1. Click the bell beside the titlebar's plus button, use View → Inbox, or find Toggle Inbox in the command palette. With the sidebar layout, Inbox brings tabs that need attention or are running toward the front and shows a line describing their activity.
The line can describe an approval, an error, an agent's current step, or its last reply. It gives you context for choosing a tab. Open that tab to read the full request or result before taking action. A short activity description cannot substitute for reviewing the actual change an agent wants to make.
Inbox also has a Continue group above its date groups. Drag rows into it when you want to keep a session close at hand for follow-up. In a tab-bar layout, the bell opens a popover of tabs needing attention. These two presentations serve the same practical purpose: finding the next session to visit while several tasks are in flight.
Hovering a tab can also show a preview card with its activity and folder. That is useful when two tasks have similar titles but belong to different projects. For the surrounding tab and split controls, see windows, tabs, and splits.
What is a useful workflow for three parallel sessions?
Give each session a bounded job with a clear review point. For example, one session can investigate a bug, another can update documentation, and a third can run an independent test task. Keep changes to shared files coordinated; a notification system helps you notice state changes, but it does not resolve conflicting edits.
Once the integrations are working, send each task and move to the work that needs your own attention. When an awaiting-input notification arrives, inspect that session first if its answer is blocking progress. When a completion arrives, review the response and evidence before deciding whether to continue, revise the task, or move on.
Use prompt queueing when the next instruction belongs to the same session and should wait for its current turn. Use another tab or split when the task can proceed independently. A serial queue and parallel sessions solve different scheduling needs, even though both reduce the time you spend waiting at a prompt.
If you need an older conversation, finding and resuming agent sessions is the relevant workflow. A notification identifies a live event; session history helps you return to context after that event has passed.
What should you check when notifications stop arriving?
Start by separating a missing lifecycle event from a hidden banner. If the session's badge or Inbox state changes correctly, focus on macOS notification permission, Focus, foreground policy, and the notification toggle for that tab. Reinstalling hooks is unlikely to fix an operating-system banner permission.
If no agent state changes appear, check that you installed the integration for the CLI you actually launched. Confirm its Config home, restart the agent, and try a short new task. An old process can keep using the configuration it loaded before the integration was installed. For OpenCode, remember to send a message after the restart.
If only one agent is affected, investigate that agent's setup before changing global settings. If ordinary command notifications work but agent notifications do not, that proves the system can display a banner, while leaving the lifecycle integration as a separate part to inspect. The task monitoring guide describes the agent-specific controls.
Avoid diagnosing a session solely from whether terminal text is moving. An agent may be thinking, running a tool, or waiting for a response without producing much output. The installed integration is intended to provide state directly; readable output and reported lifecycle state are complementary evidence.
Does keeping the Mac awake replace notifications?
Prevent Sleep While Processing helps a long local task keep running while the agent is active. It is an optional setting, separate from notification delivery. A sleeping computer cannot be made into a continuously running remote worker merely by enabling a completion banner.
Choose the sleep setting according to the machine and task. The important distinction is that keeping the computer awake addresses execution time, while notifications address your attention. Neither setting verifies the agent's answer. Read the setup guide for the additional requirements and behavior when a MacBook's lid is closed.
Common questions
Do agent notifications require shell integration?
The supported coding agent integrations report lifecycle state through Otty's IPC path, so those agent events do not require shell integration. Shell command tracking has its own integration requirements. The progress state reference explains how command progress and agent state differ.
Will a notification answer an approval prompt for me?
No. An awaiting-input notification points you back to the session. Read the request and make the decision there. Enabling notifications does not grant the agent broader permissions or make future approvals automatic.
Does task completed mean the code is ready to merge?
No. It means the current turn ended. Check the diff, the commands the agent ran, their results, and your acceptance criteria. Use the completion signal as a review trigger, especially when several sessions finish close together.
Can I use this with the agent CLI I already have?
Yes, the workflow uses your installed supported CLI and its own authentication. Otty supplies terminal-side integration and presentation around it. Otty for coding agents describes that relationship, and the setup page lists the supported integrations.
Version and sources
These instructions were checked against Otty's 1.6.2 tag and describe its macOS interface. The release notes record Inbox in 1.6.1 and Config home in 1.6.2. The linked setup, task monitoring, and notification documentation provides further background; those live pages may describe changes made after this version.