[Bug]: Long commands cause horizontal overflow in the Add Action dialog #11443
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- Open a project in T3 Code and open Add Action.
- Enter a name for the action.
- Paste a command with a long path or argument into Command. For example, paste this as a single line:
ln -s "$HOME/Code/example-project/a-very-long-directory-name/another-long-directory-name/one-more-long-directory-name/src/config/Secrets.swift" "src/config/Secrets.swift"- Inspect the dialog before saving or running the action.
I encountered this while adding a symlink command with a long file path, as shown in the screenshot.
Expected behavior
The command field and the rest of the form should stay within the dialog width, with all controls visible.
Soft word wrap in the command field could help keep long paths readable, provided it only changes the display and preserves the command text and intentional line breaks.
Actual behavior
A long command line makes the form content overflow horizontally. The right edges of the fields and helper text are clipped, controls on the right are pushed out of view, and a horizontal scrollbar appears across the bottom of the form.
This affects the layout of the whole Add Action form and makes it harder to review or configure the action.
Impact
Minor bug or occasional failure
Version or commit
Unknown; not captured in the screenshot.
Environment
macOS, T3 Code desktop app.
Logs or stack traces
Screenshots, recordings, or supporting files
Workaround
No response
Activity
juliusmarminge commentedon Sep 12, 2026
Thanks for the clear repro and screenshot — this looks like a real layout bug in the Add/Edit Action dialog.
What happens. The Command field is a shared
Textarea(apps/web/src/components/projectScriptEditor.tsx→apps/web/src/components/ui/textarea.tsx). That control usesfield-sizing: contentinside aninline-flexwrapper with nomin-w-0/max-w-full. A long unbroken path becomes the field’s min-content width, so the whole form grows past the dialog (max-w-lg).DialogPanelis aScrollAreawith horizontal overflow, which matches the clipped right edge and the scrollbar under the form.The same dialog is used from the header Add action control and from project Action settings, so both entry points are affected. Edit Action is the same component.
Not a duplicate. Closest prior work is the same overflow class, not this dialog:
Suggested fix. Layout-only. Soft-wrap the command for display (
whitespace-pre-wrap+overflow-wrap: anywhere) and constrain the field (min-w-0 max-w-full) sofield-sizing: contentgrows vertically, not sideways. That should keep the stored command and intentional line breaks unchanged. A sharedTextareaconstraint would also protect other dialogs; a local class on this field is enough to close this issue.Accepting as a minor UI bug.
fixfon commentedon Oct 11, 2026
I'd like to take this. I'll follow the direction in the maintainer triage above and open a focused PR with before/after evidence, noting the model and harness used.
fixfon commentedon Oct 11, 2026
PR is up: #18207 (one-class change to the shared
Textarea, with before/after evidence).