Pith. sign in

REVIEW 3 major objections 4 minor 45 references

NaSh: Guardrails for an LLM-Powered Natural Language Shell

T0 review · 3 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read NaSh argues that an LLM-powered shell should be architected around guardrails that let users inspect and undo what the LLM did, not around raw command execution.

desk verdict A clear position paper with a genuine hook—inverse overlays—but no implementation and an unvalidated bet on symbolic test generation. read the letter →

arxiv 2506.13028 v1 pith:B62NQ4FY submitted 2025-06-16 cs.OS cs.AI

Bimal Raj Gyawali , Saikrishna Achalla , Konstantinos Kallas , Sam Kumar This is my paper
classification cs.OScs.AI
keywords naturallanguageshellLLMagentsguardrailsinverseoverlayeffectsummariessymbolicexecutiontestgenerationundo/commit
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper's thesis is that because LLM outputs are statistically unreliable, a shell that accepts natural language must provide system-level guardrails that give users a way back from unexpected actions. To make this concrete, the authors design NaSh, an LLM-powered shell that turns prompts into analyzable code, runs that code in a sandbox with undo capability, summarizes every filesystem effect, and generates test inputs from the script's control flow. The paper is trying to establish that these guardrails, particularly delayed and independent undo of file effects, can be built without the performance and visibility costs of ordinary overlay sandboxes. A sympathetic reader would take away that natural-language shell design should treat reversibility and inspectability as primary requirements, not as afterthoughts.

What carries the argument

NaSh's load-bearing mechanism is the inverse overlay file system, the inverse of an overlay: instead of storing new file versions in a layer while leaving the base filesystem untouched, it mutates the base directly and retains old versions in a layer, yielding an undo log that supports per-operation, selective, delayed undo. The paper pairs this with three supporting mechanisms: LLM generation of code artifacts rather than direct actions, so execution is explainable and rerunnable; an effect-summary language that localizes all file additions, deletions, and modifications from each inverse-overlay layer; and a symbolic-execution engine that encodes script composition code into SMT formulas, using command annotations to handle black-box external commands and random fallback generation where annotations are missing.

What would settle it

A test: run NaSh's symbolic-execution test generator on a substantial corpus of LLM-generated shell scripts for everyday tasks and measure how often the composition/adapter separation succeeds, whether SMT encoding terminates within a timeout, and whether generated tests reach branches that random input generation misses. High failure rates on any of these would falsify the test-generation claim; separately, a long chain of uncommitted inverse-overlay operations could be checked for consistency when files are selectively restored.

Watch

Extended reading notes

Core claim

The central discovery is that an LLM-powered shell can protect users by pairing two ideas: generate code artifacts that are analyzable, and execute them under an inverse-overlay sandbox. An inverse overlay applies a command's file modifications directly to the filesystem but stashes the old versions of every changed file in a layer, so the layer acts as an undo log that can be committed or aborted long after execution; unlike stacked overlays, inverse-overlay layers do not stack, so keeping a long undo history has no lookup-cost penalty. On top of this, NaSh derives concise effect summaries that tell the user exactly what changed, and it uses symbolic execution on the script's composition code, separated from black-box external commands, to generate testing environments. The paper claims this combination protects users from unintended local filesystem actions and makes the iterative Develop-Run-Inspect-Revert cycle safer and more productive.

Load-bearing premise

The load-bearing premise is that the composition code of an LLM-generated shell script, the glue around black-box external commands, can be cleanly separated from those commands and fully analyzed by symbolic execution via SMT encoding; if real scripts interleave external commands too deeply for that separation, NaSh's test-generation guardrails cannot do their job.

Editorial extensions

If this is right

  • LLM-powered shells should generate analyzable code rather than issue system calls or clicks directly, making LLM behavior explainable, repeatable, and debuggable.
  • Users can defer undo for as long as they like without a runtime penalty, because inverse-overlay layers do not stack and only disk space bounds the history.
  • Effect summaries make the Inspect step tractable: users see every file added, deleted, or modified instead of hunting through the filesystem.
  • Script development can be tested before real harm: symbolic execution over composition code, backed by command annotations, generates inputs and throwaway sandboxed environments.
  • External side effects that cannot be undone, such as API calls, should be gated behind explicit user permission rather than executed automatically.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A reader might extend the inverse-overlay idea to any stateful tool whose users need delayed rollback, such as refactoring editors, database migration tools, or package managers, with commit and abort mirroring NaSh's semantics.
  • If NaSh's code-artifact approach works, LLM nondeterminism becomes a development-time issue rather than a runtime one: once the generated script is saved, the model's nondeterminism no longer affects re-execution.
  • The adapter/composition dichotomy suggests a concrete research test: on a corpus of real LLM-generated scripts, measure how often composition code can be cleanly extracted and symbolically executed, since low coverage would indicate the separation needs refinement.
  • The undo-context proposal for RPCs implies that future APIs will need to expose undoability, time bounds, and cost of undo as first-class interface metadata, shifting part of the responsibility from the shell to the service.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. NaSh: Guardrails for an LLM-Powered Natural Language Shell argues that an LLM-powered shell should be architected not around raw command execution but around system-level guardrails that support the Develop–Run–Inspect–Revert cycle. The paper proposes four components: generating executable and analyzable code artifacts (§3.1), a filesystem sandbox based on "inverse overlays" that support delayed commit/abort (§3.2), effect summaries for inspection (§3.3), and test generation via modality separation plus symbolic execution with command annotations (§3.4). It then discusses open problems including user feedback, undo conflicts, external API calls, and undo-friendly APIs (§4). The paper is explicitly a design exploration: it contains no implementation, measurements, or case studies, and it is honest about its scope (local filesystem state) and about the speculative nature of several mechanisms.

Significance. If the design assumptions hold, the paper makes a valuable contribution by reframing LLM-shell design around recoverability and inspection, and by proposing concrete mechanisms—inverse overlays, effect summaries, and annotation-guided symbolic execution—that could be built and evaluated. The paper also provides a useful related-work discussion connecting shell sandboxing (try, GoEX, MBOX), program analysis (PaSh/POSH annotations, KLEE), and undo/checkpointing systems (Speculator, External Synchrony). It is honest about limitations: it targets only local single-system state, acknowledges that external API calls cannot be easily sandboxed or undone, and explicitly leaves conflict detection and guardrail-friendly APIs as open problems. However, because no component is implemented or measured, the significance is entirely prospective; the paper would need a proof-of-concept and a precise characterization of its assumptions to support the central claim that NaSh's design protects users and empowers recovery.

major comments (3)
  1. [§3.2–§3.4 (overall system)] The paper presents NaSh as a system with four architectural components, but none of the components is implemented or evaluated. The central claim of §1—that NaSh's combination of code artifacts, inverse-overlay sandboxing, effect summaries, and symbolic-execution test generation "protect users from unexpected actions" and "empower users to recover"—is therefore an unvalidated design hypothesis. To make this claim load-bearing, the paper should provide at least a prototype implementation and a small evaluation: microbenchmarks for commit/abort and effect-summary generation, and a case study exercising the Develop–Run–Inspect–Revert cycle on a set of LLM-generated shell scripts. Without such evidence, the architectural argument remains speculative.
  2. [§3.2, inverse overlays] The claim that "inverse overlay layers do not stack, so there is no performance penalty to keeping a long history" needs substantiation. Even if reads go directly to the base file system, the undo log itself consists of an ordered set of per-command old-version layers. Restoring an early operation's file version after later operations have modified the same file requires locating the correct old version among potentially many layers and reconciling overlapping modifications; the paper does not specify the data structures, commit/abort procedures, or disk-space reclamation policy beyond the analogy of emptying a recycle bin. The paper's own acknowledgment in §4.2 that undoing an operation can leave applications in an inconsistent state indicates that the independence and no-penalty claims are premature without further design detail or measurement.
  3. [§3.4 and Figure 3] The assertion that "composition code is fully analyzable" is not supported by the modality separation defined in the paper. In Figure 3, the `if` conditions and the `rm` invocation are classified as adapter tasks, but the `for` loop and the surrounding control flow depend on adapter outputs (e.g., `[[ -f "$file" ]]`, `${file##*.}`, `[[ ! -f ... ]]`). Symbolic execution of the composition therefore requires modeling external commands; when command annotations are unavailable, NaSh's fallback is random input generation, as the paper states at the end of §3.4. The "fully analyzable" claim should be replaced by a precise statement of what is analyzable under which annotation coverage, and the approach should be evaluated on actual LLM-generated scripts to measure annotation coverage and SMT-solver tractability.
minor comments (4)
  1. [Figure 3] The example script contains apparent typos: the condition `" ${file##*.}" != "swp"` has a leading space before the parameter expansion, and the companion check `". $(basename "$file" ).swp"` inserts spaces around the basename. These errors make the example look like an invalid script; since the example is meant to illustrate clean modality separation, it should be corrected.
  2. [§3.2] The term "inverse overlay" is presented as if it were an established concept; the paper should either cite prior work on undoable file systems or versioning, or formally define the layer semantics (creation, lookup, commit, abort) so that the no-stacking claim can be evaluated.
  3. [§3.4] The fallback to random input and environment generation is described in a single sentence; since this is the only mechanism when annotations are absent, the paper should describe how the random generator is seeded, how the testing environment is constructed, and how results are presented to the user.
  4. [§5] The discussion of related sandboxing work would be clearer with a small table comparing MBOX, GoEX, try, and the proposed inverse overlay on dimensions such as read/write overhead, undo latency, and support for selective restore.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: NaSh is a design exploration whose claims are forward-looking architectural arguments, not derivations reduced to their own inputs or to self-citations.

full rationale

The paper does not derive a result from fitted parameters, nor does it rename a known pattern, nor does it invoke a self-authored uniqueness theorem to force its design. Its central thesis is that an LLM-powered shell should provide guardrails through analyzable code artifacts, inverse-overlay sandboxing, effect summaries, and symbolic-execution-based test generation. Each of these is presented as a proposed design or an observation about shell use, not as a mathematical derivation. The closest thing to a load-bearing assumption is in Section 3.4, where NaSh claims that composition code is fully analyzable while adapter tasks are black boxes, and that SMT-based symbolic execution can explore the control-flow space. This is an unvalidated technical bet about script structure and solver tractability, but it is not circular: it is an assumption about the world, not a conclusion that is equivalent to its own premise by construction. The paper even acknowledges the fallback in the same section: 'As a fallback mechanism, NaSh will provide random input and environment generation to test the validity of commands without annotations.' That stated limitation weakens the strength of the guarantee but does not make the reasoning circular. The authors do cite their own prior work: PaSh [41] and try [21] involve Konstantinos Kallas, and the acknowledgments thank PaSh contributors. However, these citations are used as background and as sources of annotation libraries or alternative sandboxing mechanisms, not as the justification for NaSh's central claims. PaSh and POSH are cited as external prior systems that pioneered command annotations, and NaSh merely proposes to use such libraries; the paper's contribution does not depend on those citations being true in a way that would reduce to itself. Related work is also used to position NaSh against existing systems such as AutoBash, Speculator, MBOX, GoEX, and try, with explicit trade-offs stated rather than a forced uniqueness argument. There is no fitted quantity later reported as a prediction, no self-referential definition of an output in terms of an input, and no derivation chain whose conclusion is identical to its assumptions. Accordingly, the appropriate finding is no significant circularity, score 0.

Assumptions & free parameters 0 free parameters · 6 assumptions · 3 invented entities

The central design depends on several unverified technological bets rather than fitted parameters. No numbers are fitted. The main assumptions are that LLM output can be constrained to analyzable code, that composition logic in shell scripts is separable and SMT-tractable, and that inverse overlays can be implemented efficiently. The paper postulates three entities (inverse overlay layer, effect summary language, undo contexts) without prototypes, so none has independent evidence.

assumptions (6)
  • domain assumption LLM outputs are unreliable and may corrupt or delete user data.
    Stated in §1 as the thesis motivating all guardrails; widely accepted given LLM behavior, but treated as a given.
  • domain assumption Shell use is an iterative Develop-Run-Inspect-Revert process.
    Introduced in §2 and used throughout to justify the need for undo and inspection support.
  • ad hoc to paper LLM-generated code is analyzable with program analysis techniques.
    §3.1 claims the generated code is 'not only executable, but also analyzable'; no evidence is given that real LLM code is amenable to static or symbolic analysis.
  • ad hoc to paper Composition code of shell scripts is fully analyzable by symbolic execution.
    §3.4 proposes encoding composition code into SMT formulas; this is a substantial unsupported technical assumption about script structure.
  • ad hoc to paper Inverse overlay layers impose no performance penalty for long history.
    §3.2 asserts no performance penalty without measurements, ignoring metadata and lookup costs.
  • domain assumption External effects can be prevented via network, user, and pid namespaces.
    §3.2 proposes namespaces to block API calls and process interactions; this is standard container isolation, but the paper acknowledges it is coarse-grained.
invented entities (3)
  • Inverse overlay file system layer
    purpose: Stores old versions of files when commands modify them, enabling later commit or abort of operations.
    Described in §3.2; no implementation or prototype exists.
  • Effect summary language
    purpose: Succinctly represents all changes in the system for the Inspect phase.
    Mentioned in §3.3 but never defined; no syntax or semantics are given.
  • Undo contexts
    purpose: Returned by API calls to describe constraints on undoing them and propagated through call graphs.
    Proposed in §4.4 as a future RPC extension; no system implements it.

how reviews work

0 comments
Cite this review

Pith. "Pith review of NaSh: Guardrails for an LLM-Powered Natural Language Shell." pith.science (2026). https://pith.science/paper/B62NQ4FY

@misc{pith2026250613028,
  author       = {Pith},
  title        = {Pith review of: NaSh: Guardrails for an LLM-Powered Natural Language Shell},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/B62NQ4FY}},
  note         = {Machine review of arXiv:2506.13028}
}
read the original abstract

We explore how a shell that uses an LLM to accept natural language input might be designed differently from the shells of today. As LLMs may produce unintended or unexplainable outputs, we argue that a natural language shell should provide guardrails that empower users to recover from such errors. We concretize some ideas for doing so by designing a new shell called NaSh, identify remaining open problems in this space, and discuss research directions to address them.

Figures

Figures reproduced from arXiv: 2506.13028 by the authors.

Figure 1
Figure 1. Shell use: inner cycle corresponds to interac [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. NaSh architecture. However, LLMs can produce incorrect answers or take incorrect actions. While users of traditional shells may also make mistakes, LLMs exacerbate the problem because the user is more distant from the precise logic behind the exe￾cution, making it harder to predict what might go wrong and ultimately notice the mistakes. For example, if an LLM￾powered shell script unexpectedly produces files in a dir… view at source ↗
Figure 3
Figure 3. An example script that deletes all files in a [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

45 extracted references · 38 canonical work pages

  1. [1]

    Rajeev Alur, Rastislav Bodik, Garvit Juniwal, Milo MK Martin, Mukund Raghothaman, Sanjit A Seshia, Rishabh Singh, Armando Solar-Lezama, Emina Torlak, and Abhishek Udupa. 2013. Syntax-guided synthesis. IEEE

    work page 2013

  2. [2]

    Thomas Anderson and Michael Dahlin. 2014. Operating Systems: Principles and Practice (2nd ed.). Recursive Books, Chapter 14

    work page 2014

  3. [3]

    Anthropic. 2024. Developing a computer use model. https://www. anthropic.com/news/developing-computer-use. Accessed: December 19, 2024

    work page 2024

  4. [4]

    Benjamin Bengfort. 2021. Contexts in Go Microservice Chains. https: //rotational.io/blog/contexts-in-go-microservice-chains/. Accessed: January 14, 2025

    work page 2021

  5. [6]

    Cristian Cadar, Daniel Dunbar, and Dawson Engler. 2008. KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs. In OSDI. USENIX

    work page 2008

  6. [7]

    Sherman Chann. 2023. Non-determinism in GPT-4 is caused by Sparse MoE. https://152334h.github.io/blog/non-determinism-in-gpt-4/. Accessed: January 12, 2025

    work page 2023

  7. [8]

    Petros Efstathopoulos, Maxwell Krohn, Steve VanDeBogart, Cliff Frey, David Ziegler, Eddie Kohler, David Mazières, Frans Kaashoek, and Robert Morris. 2005. Labels and Event Processes in the Asbestos Operating System. In SOSP. ACM

    work page 2005

  8. [9]

    Cox, Jaeyon Jung, Patrick McDaniel, and Anmol N

    William Enck, Peter Gilbert, Byung-Gon Chun, Landon P. Cox, Jaeyon Jung, Patrick McDaniel, and Anmol N. Sheth. 2010. TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones. In OSDI. USENIX

    work page 2010

Show all 45 references
  1. [10]

    Tal Garfinkel, Ben Pfaff, and Mendel Rosenblum. 2004. Ostia: A Del- egating Architecture for Secure System Call Interposition. In NDSS. Internet Society

    2004

  2. [11]

    Github. 2024. Github CLI Copilot. https://docs.github.com/en/copilot/ using-github-copilot/using-github-copilot-in-the-command-line. Ac- cessed: January 12, 2025

    2024

  3. [12]

    Ian Goldberg, David Wagner, Randi Thomas, and Eric A. Brewer. 1996. A Secure Environment for Untrusted Helper Applications: Confining the Wily Hacker. In USENIX Security. USENIX

    1996

  4. [13]

    Andrew Head, Codanda Appachu, Marti A Hearst, and Björn Hart- mann. 2015. Tutorons: Generating context-relevant, on-demand expla- nations and demonstrations of online code. In 2015 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC) . IEEE, 3–12

    2015

  5. [14]

    Docker Inc. 2025. Develop faster. Run anywhere. https://www.docker. com/. Accessed: January 12, 2025

    2025

  6. [15]

    Tony Ivchenko. 2024. GPT-4 Non-Deterministic Behavior: A Deep Dive Into the Dark Mystery. https://medium.com/@toxa.ivchenko/gpt- 4-non-deterministic-behavior-a-deep-dive-into-the-dark-mystery- 373cbe683e4e. Accessed: January 12, 2025

    2024

  7. [16]

    Jain and R

    K. Jain and R. Sekar. 2000. User-Level Infrastructure for System Call Interposition: A Platform for Intrusion Detection and Confinement. In NDSS. Internet Society

    2000

  8. [17]

    Taesoo Kim and Nickolai Zeldovich. 2013. Practical and effective sand- boxing for non-root users. In2013 USENIX Annual Technical Conference (USENIX ATC 13). 139–144

    2013

  9. [18]

    Yaniv Leviathan and Yossi Matias. 2018. Google Duplex: An AI System for Accomplishing Real-World Tasks Over the Phone. https://research.google/blog/google-duplex-an-ai-system-for- accomplishing-real-world-tasks-over-the-phone/. Accessed: January 5, 2025. 6 NaSh: Guardrails for...

    2018

  10. [19]

    Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. 2021. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. arXiv:2005.1140...

    2021 arXiv

  11. [20]

    Yuanchun Li, Hao Wen, Weijun Wang, Xiangyu Li, Yizhen Yuan, Guo- hong Liu, Jiacheng Liu, Wenxing Xu, Xiang Wang, Yi Sun, Rui Kong, Yile Wang, Hanfei Geng, Jian Luan, Xuefeng Jin, Zilong Ye, Guan- jing Xiong, Fan Zhang, Xiang Li, Mengwei Xu, Zhijun Li, Peng Li, Yang Liu, Ya-Qin...

    2024 arXiv

  12. [21]

    Georgios Liargkovas, Konstantinos Kallas, Michael Greenberg, and Nikos Vasilakis. 2023. Executing Shell Scripts in the Wrong Order, Cor- rectly. In Proceedings of the 19th Workshop on Hot Topics in Operating Systems. 103–109

    2023

  13. [22]

    LinuxContainers. 2024. What’s LXC? https://linuxcontainers.org/lxc/ introduction/. Accessed: January 12, 2025

    2024

  14. [23]

    Kim Martineau. 2024. Large language models revolutionized AI. LLM agents are what’s next. https://research.ibm.com/blog/what-are-ai- agents-llm. Accessed: December 19, 2024

    2024

  15. [24]

    Emmett McFarlane. 2024. engshell: An English-language shell for any OS, powered by LLMs. https://github.com/emcf/engshell. Accessed: January 12, 2025

    2024

  16. [25]

    M. D. McIlroy, E. N. Pinson, and B. A. Tague. 1978. UNIX Time-Sharing System: Foreword. The Bell System Technical Journal 57, 6 (1978), 1899–

    1978

  17. [26]

    Andrew C. Myers. 1999. JFlow: Practical Mostly-Static Information Flow Control. In POPL. ACM

    1999

  18. [27]

    Jakob Nielsen. 1993. Noncommand user interfaces. Commun. ACM 36, 4 (April 1993), 83–99. https://doi.org/10.1145/255950.153582

    1993

  19. [28]

    Nightingale, Peter M

    Edmund B. Nightingale, Peter M. Chen, and Jason Flinn. 2005. Specu- lative execution in a distributed file system. SIGOPS Oper. Syst. Rev. 39, 5 (Oct. 2005), 191–205. https://doi.org/10.1145/1095809.1095829

    2005

  20. [29]

    Nightingale, Kaushik Veeraraghavan, Peter M

    Edmund B. Nightingale, Kaushik Veeraraghavan, Peter M. Chen, and Jason Flinn. 2006. Rethink the Sync. In OSDI. USENIX

    2006

  21. [30]

    Shishir Patil. 2023. Gorilla CLI. https://github.com/gorilla-llm/gorilla- cli. Accessed: January 12, 2025

    2023

  22. [31]

    Patil, Tianjun Zhang, Vivian Fang, Noppapon C., Roy Huang, Aaron Hao, Martin Casado, Joseph E

    Shishir G. Patil, Tianjun Zhang, Vivian Fang, Noppapon C., Roy Huang, Aaron Hao, Martin Casado, Joseph E. Gonzalez, Raluca Ada Popa, and Ion Stoica. 2024. GoEX: Perspectives and Designs Towards a Runtime for Autonomous LLM Applications. arXiv:2404.06921 [cs.CL] https://arxiv.o...

    2024 arXiv

  23. [32]

    Gonzalez

    Shishir G Patil, Tianjun Zhang, Xin Wang, and Joseph E. Gonzalez

  24. [33]

    Jan-Simon Pendry and Marshall Kirk McKusick. 1995. Union Mounts in 4.4BSD-Lite. In USENIX 1995 Technical Conference (USENIX 1995 Technical Conference). USENIX

    1995

  25. [34]

    Joan Puigcerver, Carlos Riquelme, Basil Mustafa, and Neil Houlsby. 2024. From Sparse to Soft Mixtures of Experts. arXiv:2308.00951 [cs.LG] https://arxiv.org/abs/2308.00951

    2024 arXiv

  26. [35]

    Deepti Raghavan, Sadjad Fouladi, Philip Levis, and Matei Zaharia

  27. [36]

    Martin P Robillard and Yam B Chhetri. 2015. Recommending reference API documentation. Empirical Software Engineering 20, 6 (2015), 1558– 1586

    2015

  28. [37]

    Ya-Yunn Su, Mona Attariyan, and Jason Flinn. 2007. AutoBash: im- proving configuration management with operating system causal- ity analysis. SIGOPS Oper. Syst. Rev. 41, 6 (Oct. 2007), 237–250. https://doi.org/10.1145/1323293.1294284

    2007

  29. [38]

    Kent Sullivan. 1996. The Windows 95 user interface: a case study in usability engineering. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Vancouver, British Columbia, Canada) (CHI ’96). Association for Computing Machinery, New York, NY, USA, 473...

    1996

  30. [39]

    Andries van Dam. 1997. Post-WIMP user interfaces. Commun. ACM 40, 2 (Feb. 1997), 63–67. https://doi.org/10.1145/253671.253708

    1997

  31. [40]

    Tanay Varshney. 2023. Introduction to LLM Agents. https://developer. nvidia.com/blog/introduction-to-llm-agents/. Accessed: December 19, 2024

    2023

  32. [41]

    Nikos Vasilakis, Konstantinos Kallas, Konstantinos Mamouras, Achilles Benetopoulos, and Lazar Cvetkovi`c. 2021. PaSh: Light-touch Data-Parallel Shell Processing. In EuroSys. ACM

    2021

  33. [42]

    Warp. 2025. The Intelligent Terminal. https://www.warp.dev/. Ac- cessed: January 13, 2025

    2025

  34. [43]

    Nickolai Zeldovich, Silas Boyd-Wickizer, Eddie Kohler, and David Mazières. 2006. Making Information Flow Explicit in HiStar. In OSDI. USENIX. 7

    2006

  35. [1904]

    https://doi.org/10.1002/j.1538-7305.1978.tb02135.x

    1978

  36. [2020]

    In 2020 USENIX Annual Technical Conference (USENIX ATC 20)

    POSH: A Data-Aware Shell. In 2020 USENIX Annual Technical Conference (USENIX ATC 20). USENIX Association, 617–631. https: //www.usenix.org/conference/atc20/presentation/raghavan

    2020

  37. [2024]

    In The Thirty-eighth Annual Conference on Neural Information Processing Systems

    Gorilla: Large Language Model Connected with Massive APIs. In The Thirty-eighth Annual Conference on Neural Information Processing Systems. https://openreview.net/forum?id=tBRNC6YemY

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.