You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support tmux configuration files in agent containers
Description
Problem
User tmux configurations (prefix key, mode-keys, custom bindings) are ignored when Scion launches agent containers, even when the config file exists at ~/.tmux.conf inside the container. This affects user experience when interacting with agents via scion attach.
Current Behavior
Scion hardcodes the tmux invocation in pkg/runtime/common.go:413-415:
Also updatepkg/runtime/k8s_runtime.go with same change.
Benefits:
✅ Simple one-line change
✅ Respects user preferences
✅ Standard tmux behavior
✅ No breaking changes (if file missing, tmux falls back to defaults)
Fallback safety: If ~/.tmux.conf doesn't exist, tmux silently uses defaults.
Solution 2: Make Hook Timing Reliable (Alternative)
Document how to make post-start hooks work reliably with tmux:
Add $HOME environment to hook execution
Ensure hook runs after tmux socket is available
Add retry logic in hook system
Benefits:
✅ More flexible (works for other config files)
❌ More complex
❌ Timing still tricky
Solution 3: Configuration Option (Most Flexible)
Add harness config option:
# ~/.scion/harness-configs/pi-sonnet/config.yamltmux:
config_file: ~/.tmux.conf # or null to use defaultsoptions:
- "set-option -g prefix C-a"
- "setw -g mode-keys vi"
Benefits:
✅ Most flexible
✅ Doesn't require baking config into image
❌ Most complex to implement
❌ Yet another config layer
Impact & Use Cases
Who This Affects
Current workaround for affected users: Use --no-hub mode, which loses Hub features (secrets management, web UI, broker coordination).
Affected users:
Power users with muscle memory for custom tmux keybindings
Teams standardizing on specific tmux configs across agents
Users with accessibility needs requiring specific keybindings
Vim users who expect vi-mode in copy/paste operations
Real-World Scenario
User has Ctrl-a prefix and vi-mode in their local tmux. When they scion attach to debug an agent, they:
Press Ctrl-a d to detach → nothing happens (prefix is still Ctrl-b)
Enter copy mode → emacs keys, not vi keys
Repeatedly hit wrong keybindings, slowing down debugging
Testing
Test Case 1: Config File Present
# In Dockerfile
COPY tmux.conf /home/scion/.tmux.conf
# After agent starts
$ tmux show-options -g prefix
prefix C-a # ✅ Should show user's custom prefix
$ tmux show-options -g mode-keys
mode-keys vi # ✅ Should show user's custom mode
Test Case 2: No Config File
# Don't add tmux.conf to image# After agent starts
$ tmux show-options -g prefix
prefix C-b # ✅ Should fall back to defaults
$ tmux show-options -g mode-keys
mode-keys emacs # ✅ Should fall back to defaults
Test Case 3: Invalid Config
# Add broken tmux.conf
COPY broken-tmux.conf /home/scion/.tmux.conf
# tmux should fail gracefully with error message# Container should still start (don't fail hard on bad config)
Support tmux configuration files in agent containers
Description
Problem
User tmux configurations (prefix key, mode-keys, custom bindings) are ignored when Scion launches agent containers, even when the config file exists at
~/.tmux.confinside the container. This affects user experience when interacting with agents viascion attach.Current Behavior
Scion hardcodes the tmux invocation in
pkg/runtime/common.go:413-415:This starts tmux without the
-fflag, so tmux uses its built-in defaults:prefix C-b(not user's preferredC-a)mode-keys emacs(not user's preferredvi)Expected Behavior
When a user has a tmux config file at
~/.tmux.conf(either baked into their custom image or synced via harness configs), tmux should load and use it.Reproduction Steps
Create custom Dockerfile with user's tmux config:
Build and push image to ECR
Start agent using custom image:
scion start test-agent "Simple task"Attach to agent:
Check tmux settings:
Verify config exists:
Result: Config file exists but is not loaded by tmux.
Investigation & Root Cause
1. Primary Issue: Missing
-fFlagThe tmux command in
pkg/runtime/common.goandpkg/runtime/k8s_runtime.godoes not include-f ~/.tmux.conf:Current:
Should be:
tmux -f ~/.tmux.conf new-session -d -s scion -n agent ...2. Attempted Workarounds
Workaround A: Manual Reload (Doesn't Persist)
tmux source-file ~/.tmux.confWorkaround B: Post-Start Hook (Timing Issues)
Added hook at
/etc/scion/hooks/post-start.d/10-reload-tmux-config:Result:
Running post-start hooks...)Workaround C: Harness Config Home Files (Doesn't Work in Hub Mode)
Placing config in
~/.scion/harness-configs/pi-sonnet/home/.tmux.conf:--no-hublocal mode3. Related Issues
This issue is related to:
Proposed Solutions
Solution 1: Add
-f ~/.tmux.confFlag (Preferred)Modify
pkg/runtime/common.goline 413:Also update
pkg/runtime/k8s_runtime.gowith same change.Benefits:
Fallback safety: If
~/.tmux.confdoesn't exist, tmux silently uses defaults.Solution 2: Make Hook Timing Reliable (Alternative)
Document how to make post-start hooks work reliably with tmux:
$HOMEenvironment to hook executionBenefits:
Solution 3: Configuration Option (Most Flexible)
Add harness config option:
Benefits:
Impact & Use Cases
Who This Affects
Current workaround for affected users: Use
--no-hubmode, which loses Hub features (secrets management, web UI, broker coordination).Affected users:
Real-World Scenario
User has Ctrl-a prefix and vi-mode in their local tmux. When they
scion attachto debug an agent, they:Ctrl-a dto detach → nothing happens (prefix is still Ctrl-b)Testing
Test Case 1: Config File Present
Test Case 2: No Config File
Test Case 3: Invalid Config
Implementation Notes
Files to Modify
pkg/runtime/common.go(line ~413):pkg/runtime/k8s_runtime.go(similar location):Same change for Kubernetes runtime
Tests to update:
pkg/runtime/common_test.go- update expected tmux commandspkg/runtime/k8s_runtime_tmux_test.go- sameBackward Compatibility
✅ No breaking changes: If
~/.tmux.confdoesn't exist, tmux silently uses built-in defaults (standard tmux behavior).Documentation to Update
-fflag for debugging tmux issuesEnvironment
mainbranch (commit d20a238+)scion-pi:latestwith tmux.conf baked inAdditional Context
Example Custom Config
User's
~/.tmux.confthat should be loaded:Logs Showing Hook Execution
From
scion logs test-agent:Hook was called but config not loaded (timing/environment issue).
Questions for Maintainers
Is Solution 1 (adding
-f ~/.tmux.conf) acceptable? Any concerns about the change?Should we also support a
TMUX_CONFenv var override?Post-start hooks: What's the intended use case? Our hook executes but can't reliably interact with tmux. Is this expected?
Hub mode vs local mode: Related to Hub-dispatched agents do not apply harness config or template volumes #101 - is there a roadmap for making harness home files work in Hub mode, or should users bake configs into images?
Workaround (Until Fixed)
For users who need custom tmux configs NOW:
Option A: Use --no-hub Mode
scion start --no-hub agent-name "task"Option B: Manually Reload After Attach
Option C: Alias in Shell RC
Add to image's
~/.zshrcor~/.bashrc:Then run
taafter attaching.References
man tmux, specifically-f fileflagpkg/sciontool/hooks/lifecycle.gopkg/runtime/common.go:413-415Would appreciate any guidance on the preferred solution! Happy to submit a PR for Solution 1 if that direction makes sense.