Skip to content

A way to view full output of background terminals #16935

Closed as duplicate
Closed as duplicate

Description

@MikukuOvO

What variant of Codex are you using?

CLI

What feature would you like to see?

What issue are you seeing?

I’m using Codex CLI to run long-running ML jobs (e.g., training / rollout), and the current /ps command only shows a summarized preview (last few lines) of background terminals.

There is currently no clear way to view the full live output of a running background task.


What is the expected behavior?

There should be a way to:

  • Attach to a background terminal (similar to tmux attach)
  • Or expand /ps into a full log view
  • Or stream full stdout of a selected job

Why is this important?

For long-running workloads, logs are critical for:

  • debugging
  • monitoring progress
  • detecting failures early

The current summarized view is not sufficient for these use cases.


Suggested solutions

  • Add /attach <job_id> to open full terminal view
  • Add /logs <job_id> to stream full output
  • Or allow toggling between "preview" and "full" mode in /ps

Additional context

This feels like a limitation compared to tools like tmux/screen, where full session output is accessible.

Better observability for background tasks would significantly improve the developer experience when using Codex CLI.

Additional information

No response

Activity

  1. added
    CLIIssues related to the Codex CLI
    TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal display
    on Apr 6, 2026
  2. github-actions commented on Apr 6, 2026

    @github-actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. changed the title [-]No way to view full output of background terminals (/ps only shows preview)[/-] [+]A way to view full output of background terminals[/+] on Apr 6, 2026
  4. Keesan12 commented on May 18, 2026

    @Keesan12

    Full output matters, but the operator also needs a stable boundary between human inspection and model context. An /attach or /logs path that gives the human the full stream without forcing that whole stream back through the model would be ideal. Otherwise background jobs are either opaque or they become token sinks. That same separation between operator-visible receipts and model-visible context has been really important in MartinLoop-style runtimes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displayenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions