aws / aws/amazon-q-developer-cli
[feature] Support running background processes
- Vorherrschende Sprache
- Rust
- Sterne
- 2k
- Forks
- 439
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beschreibung
### Checks
- [x] I have searched [github.com/aws/amazon-q-developer-cli/issues](https://github.com/aws/amazon-q-developer-cli/issues?q=) and there are no duplicates of my issue
- [x] I have run `q doctor` in the affected terminal session
- [x] I have run `q restart` and replicated the issue again
### Operating system
macOS 15.3.1 (24D70)
### Expected behaviour
When asking chat to debug a web application that involves running a local server, expected behavior is that chat runs a webserver, runs required checks, makes a decision that website responds as required, stops local server and continues with its decisions.
### Actual behaviour
The current issue happens when "q chat" makes a decision to run a local server in a current terminal window. This sends the current terminal session into a "running server" mode and stops any further actions from q chat as it loses control over the terminal. Typing "y" or using "enter" do not affect anything. When using "CTRL+C", chat loses the chain of thought
### Steps to reproduce
Ask to create a python flask application and then ask chat to debug the website to see if it works.
### Environment
```yaml
[q-details]
version = "1.7.2"
hash = "b6bf5f1675dd7395009e8bc65c1145820671f211"
date = "2025-03-21T01:36:16.66764Z (19h ago)"
variant = "full"
[system-info]
os = "macOS 15.3.1 (24D70)"
chip = "Apple M1 Pro"
total-cores = 10
memory = "32.00 GB"
[environment]
cwd = "/Users/USER/Documents/aws/samples/q chat/personalize-casino-demo"
cli-path = "/Users/USER/Documents/aws/samples/q chat/personalize-casino-demo"
os = "Mac"
shell-path = "/bin/zsh"
shell-version = "5.9"
terminal = "VSCode"
install-method = "unknown"
[env-vars]
PATH = "/Users/USER/Documents/aws/samples/q chat/personalize-casino-demo/venv/bin:/opt/homebrew/bin:/Library/Frameworks/Python.framework/Versions/3.12/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Users/USER/.vscode/extensions/ms-python.python-2025.2.0-darwin-arm64/python_files/deactivate/zsh:/Users/USER/.pyenv/versions/3.8.12/bin:/opt/homebrew/bin:/Library/Frameworks/Python.framework/Versions/3.12/bin:/Users/USER/.local/bin"
QTERM_SESSION_ID = "38b2f8a58ec548a8b6e711aa74579a77"
Q_SET_PARENT_CHECK = "1"
Q_TERM = "1.7.1"
SHELL = "/bin/zsh"
TERM = "xterm-256color"
ZDOTDIR = "/Users/USER"
__CFBundleIdentifier = "com.microsoft.VSCode"
```
Beitragsleitfaden
Rechercherichtung
Beginne beim q chat-Befehl und seinem Pfad zur Prozessausführung im Terminal; im Issue werden keine Repository-Dateien oder Tests genannt. Reproduziere das Problem mit einer Python-Flask-App und beobachte, wie ein im Vordergrund laufender Server die Steuerung beeinflusst. Erledigt ist die Aufgabe, wenn chat den Server starten, Prüfungen durchführen, ihn stoppen und seine Entscheidungen ohne Verlust des Kontexts fortsetzen kann.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- flask, python, rust, zsh
- Bereich
- cli, operating-systems
- Issue-Typ
- Feature
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Veraltet
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 35/100