Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

agy-tui: permission Yes is cursor-dependent, and supervisor stderr overlays the live TUI (field send/receive now works on our fork)

Open
  • Is something wrong?
#1,268 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python, shell
Domain
cli, developer-experience, tooling

Research direction

Start in antigravity-tui-supervisor.py: the permission check that still requires the token > 1. Yes (required tuple and 'yes' diagnostic) and permission_input_rejection_reason() when the highlight moves off option 1. Treat option-1 text 1. Yes as the required token inside the existing footer/nav-bounded modal and request < question < yes order, without treating option 2/3 wording as Yes. For stderr overlay, queue notices while self.master is not None and flush after close() restores termios. Done when a complete permission modal still accepts Yes after the cursor leaves option 1, live idle TUI is not overwritten by supervisor notices, and fail reasons still print on the shell at exit. Field-tested fork commits are described on the issue; this is not a first-timer change.

Written by the indexing model from the issue text.

Description

Field result

On Linux we run agy-tui (PTY supervisor + interactive agy, same --name).
After two fork-only fixes (below) we confirmed agmsg send and receive through
that TUI succeed.

This is an operator-confirmed field result on joelmitz/agmsg at
89403d9b (installed skill v1.3.0-83-g89403d9). We are not claiming a
reproduction on fujibee/agmsg main.

Related but distinct from #1263 (incomplete-frame / permission-nav-missing
during a redraw). Today's halt was a complete permission modal whose
required token disappeared when the cursor moved off option 1.

Bug 1 — > 1. Yes is a cursor position, not "option 1 exists"

origin/main antigravity-tui-supervisor.py still requires > 1. Yes
(around the required=(..., '> 1. Yes') check and the 'yes':'> 1. Yes'
diagnostic token).

On a real permission prompt, moving the highlight to option 2 or 3 redraws
option 1 without >:

  1. Yes, run command
> 2. Yes, and always allow in this conversation for commands that start with ...

permission_input_rejection_reason() then returns permission-body-incomplete
(positions.yes=[] while raw_seen.yes=True). The supervisor fail()s,
leaves the batch unread, and stops (durableAttention / 停止/要確認).

This is fail-closed (over-refusal), not a bypass. The modal was real; only
the cursor marker had moved.

Fork fix (already on joelmitz/agmsg main, independently reviewed):

  • 0618071ae756cd316d69b7f343080a137ff06e6b
  • Required token is 1. Yes (option 1 text), still inside the existing
    footer/nav-bounded modal window and request < question < yes order check.
  • Option 2/3 wording is not treated as Yes.

Bug 2 — supervisor stderr is drawn on the same tty as agy

origin/main prints live notices to stderr while the child PTY is attached.
Parent stderr is the same terminal agy is painting, so the idle prompt becomes:

>
[agmsg] 空の入力待ちを確認したため自動配送を再開しました────────
? for shortcuts

Pause/resume are already visible via agy-tui status (paused / running).

Fork fix (same main, independently reviewed):

  • 89403d9b9db9a400c16582610e11d3e25fe9f199
  • While self.master is not None, notices are queued; close() restores
    termios then flushes so fail reasons still appear on the shell.
  • Live idle after this change was clean in the field.

Known leftover: a flush at close() can still land on the last TUI frame
as the process exits. That is exit-time, not the live prompt.

Why not a PR yet

Same reason as #1263: these patches are on the fork, reviewed there, and
field-tested there. Happy to open PRs against origin/main if you want
them, or to split (1) and (2) into separate issues.

We are not asking you to take the snapshot/consume design from #1263
as part of this; that is a different halt class.

Dominant language
Shell
Stars
1.5k
Forks
156
Avg merge
21h 36m
Merged PRs (30d)
197

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fujibee/agmsg

All issues in fujibee/agmsg

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.